[TLS] TLS WG Virtual Interim on FATT Process

[Sean Turner]

The chairs would like to have an interim to review the FATT (Formal Analysis 
Triage Team) process. We are still working out the proposal, but we would like 
to get this meeting scheduled to review any feedback / comments once we do post 
the process. Please fill out the following with your available times if you are 
interested in attending:

https://doodle.com/meeting/participate/id/aMoXAp1d

Thanks,
Deirdre, Joe, & Sean
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Sean Turner]

Hi! There is consensus to adopt this draft as a working group item.* This might 
not be the exact form it ends up in, but there is sufficient interest to get 
the work started. I'll work with the authors to migrate to the official 
repository and submit an updated draft.

spt

* Apologies for taking so long. Some of the delay was a result of working on 
the FATT process.

> On Jul 25, 2024, at 12:39, 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] Re: Adoption call for SSLKEYLOG Extension file for ECH

[Sean Turner]

Hi! There is consensus to adopt this draft as a working group item.*  I'll work 
with the authors to migrate to the official repository and submit an updated 
draft.

spt

* Apologies for taking so long. Some of the delay was a result of working on 
the FATT process.

> On Jul 25, 2024, at 12:15, Sean Turner  wrote:
> 
> 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] Re: DTLS 1.3 ACKs near the version transition

[Eric Rescorla]

Hi David,

Thanks for digging in here. I haven't fully processed your comments, but it
does seem like we probably do need a -bis. Now that we've gotten 8446-bis
and ECH out the door, I don't think this is implausible. Do you feel like
you are getting close to a complete list of issues to be addressed there?

-Ekr



On Mon, Sep 23, 2024 at 3:44 PM David Benjamin 
wrote:

> For my neck of the woods, DTLS matters for WebRTC. It really should be
> QUIC, but alas it isn't and I suspect redesigning all of WebRTC now atop
> QUIC and then fully completing the transition would take much longer than
> getting to DTLS 1.3, much as the DTLS 1.3 specification needs a -bis
> document. :-)
>
> On Mon, Sep 23, 2024 at 6:10 PM Watson Ladd  wrote:
>
>> Backing up a bit, at what point do we say QUIC Datagram is the right
>> way to do this?
>>
>> This whole adventure sounds like a mess.
>>
>> On Fri, Sep 20, 2024 at 8:20 AM David Benjamin 
>> wrote:
>> >
>> > (Resending since I don't see these two mails in the list archives, so
>> I'm not sure if the list software broke again. Apologies if this is a
>> duplicate mail!)
>> >
>> > On Thu, Sep 19, 2024 at 1:49 PM David Benjamin 
>> wrote:
>> >>
>> >> On Thu, Sep 19, 2024 at 1:31 PM David Benjamin 
>> wrote:
>> >>>
>> >>> Ah fun, another issue in this document. So not only are write epoch
>> lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes are
>> specified but wrong.
>> >>>
>> >>> Section 4.2.1 says:
>> >>>
>> >>> > Because DTLS records could be reordered, a record from epoch M may
>> be received after epoch N (where N > M) has begun. Implementations SHOULD
>> discard records from earlier epochs but MAY choose to retain keying
>> material from previous epochs for up to the default MSL specified for TCP
>> [RFC0793] to allow for packet reordering. (Note that the intention here is
>> that implementers use the current guidance from the IETF for MSL, as
>> specified in [RFC0793] or successors, not that they attempt to interrogate
>> the MSL that the system TCP stack is using.)
>> >>>
>> >>> https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1
>> >>>
>> >>> First, it's a bit weird to say you SHOULD discard records but MAY
>> retain keying material. I assume that meant SHOULD discard records but MAY
>> process records anyway up to MSL. Anyway, this model implies that only one
>> read epoch is active at once, but this isn't true. You basically have to
>> read epoch 1 (early data) as unordered relative to epoches 0 and 2.
>> Consider a DTLS 1.3 server:
>> >>>
>> >>> 1. The server reads ClientHello with early_data extension at epoch 0
>> and accepts early data.
>> >>> 2. The server sends ServerHello (epoch 0), EE..Finished (epoch 2),
>> and activates write epoch 3 for half-RTT application data.
>> >>> 3. The server reads early data (epoch 1) from the client. The RFC
>> would lead you to think the server can close read epoch 0 now, but...
>> >>> 4. ServerHello gets lost and, if we are to believe
>> https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8, the client
>> might send an empty plaintext ACK to trigger a retransmit. This ACK will be
>> at epoch 0. This only works if the server keeps read epoch 0 open!
>> >>> 5. Client eventually gets the ServerHello but now it only gets half
>> of the epoch 2 data. It sends an ACK to trigger another retransmit. This
>> ACK will come at epoch 2.
>> >>> 6. Server receives that ACK at epoch 2 and retransmits. The RFC would
>> lead you to think the server can close read epoch 1 now, but...
>> >>> 7. Let's say that retransmit is lost again, or hasn't arrived yet.
>> From the client's perspective, it has a connection that has yet to reach
>> the 1-RTT point, so any data from the calling application will still be
>> sent as early data. That means the client will continue to send early data
>> at epoch 1. This only works if the server keeps read epoch 1 open!
>> >>> 8. The handshake progresses and the server finally gets 1-RTT data at
>> epoch 3 from the client. Now the spirit of the rule in the text applies to
>> epoch 1 and the server can close the epoch (after optionally waiting a
>> spell for reordering)
>> >>
>> >>
>> >> Ah right, Nick Harper points out that servers really should close read
>> epoch 1 [up to a delay to accommodate reordering] as soon as they receive
>> the Finished message (epoch 2) and complete the handshake, not wait for an
>> epoch 3 record. (But it must specifically be on handshake completion, not
>> any epoch 2 record. Record-layer only logic cannot assume 1 < 2 because 2
>> might contain pre-Finished ACKs.)
>> >>
>> >> All this is missing from the specification. :-) I think we need to
>> rewrite the spec text on epochs to more explicitly discuss their lifetimes.
>> >>
>> >>>
>> >>> So the rule is actually that we close according to a partially
>> ordered set:
>> >>> - 0 (unencrypted) < 2 (handshake) < 3 (first app data) < 4 < 5 < ...
>> >>> - 1 (early data) < 3 (first app data) < 4 < 5 < ...
>> >>

[TLS] Publication has been requested for draft-ietf-tls-esni-22

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-tls-esni-22 as Proposed 
Standard on behalf of the TLS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/


___
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

[Watson Ladd]

Backing up a bit, at what point do we say QUIC Datagram is the right
way to do this?

This whole adventure sounds like a mess.

On Fri, Sep 20, 2024 at 8:20 AM David Benjamin  wrote:
>
> (Resending since I don't see these two mails in the list archives, so I'm not 
> sure if the list software broke again. Apologies if this is a duplicate mail!)
>
> On Thu, Sep 19, 2024 at 1:49 PM David Benjamin  wrote:
>>
>> On Thu, Sep 19, 2024 at 1:31 PM David Benjamin  wrote:
>>>
>>> Ah fun, another issue in this document. So not only are write epoch 
>>> lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes are 
>>> specified but wrong.
>>>
>>> Section 4.2.1 says:
>>>
>>> > Because DTLS records could be reordered, a record from epoch M may be 
>>> > received after epoch N (where N > M) has begun. Implementations SHOULD 
>>> > discard records from earlier epochs but MAY choose to retain keying 
>>> > material from previous epochs for up to the default MSL specified for TCP 
>>> > [RFC0793] to allow for packet reordering. (Note that the intention here 
>>> > is that implementers use the current guidance from the IETF for MSL, as 
>>> > specified in [RFC0793] or successors, not that they attempt to 
>>> > interrogate the MSL that the system TCP stack is using.)
>>>
>>> https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1
>>>
>>> First, it's a bit weird to say you SHOULD discard records but MAY retain 
>>> keying material. I assume that meant SHOULD discard records but MAY process 
>>> records anyway up to MSL. Anyway, this model implies that only one read 
>>> epoch is active at once, but this isn't true. You basically have to read 
>>> epoch 1 (early data) as unordered relative to epoches 0 and 2. Consider a 
>>> DTLS 1.3 server:
>>>
>>> 1. The server reads ClientHello with early_data extension at epoch 0 and 
>>> accepts early data.
>>> 2. The server sends ServerHello (epoch 0), EE..Finished (epoch 2), and 
>>> activates write epoch 3 for half-RTT application data.
>>> 3. The server reads early data (epoch 1) from the client. The RFC would 
>>> lead you to think the server can close read epoch 0 now, but...
>>> 4. ServerHello gets lost and, if we are to believe 
>>> https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8, the client might 
>>> send an empty plaintext ACK to trigger a retransmit. This ACK will be at 
>>> epoch 0. This only works if the server keeps read epoch 0 open!
>>> 5. Client eventually gets the ServerHello but now it only gets half of the 
>>> epoch 2 data. It sends an ACK to trigger another retransmit. This ACK will 
>>> come at epoch 2.
>>> 6. Server receives that ACK at epoch 2 and retransmits. The RFC would lead 
>>> you to think the server can close read epoch 1 now, but...
>>> 7. Let's say that retransmit is lost again, or hasn't arrived yet. From the 
>>> client's perspective, it has a connection that has yet to reach the 1-RTT 
>>> point, so any data from the calling application will still be sent as early 
>>> data. That means the client will continue to send early data at epoch 1. 
>>> This only works if the server keeps read epoch 1 open!
>>> 8. The handshake progresses and the server finally gets 1-RTT data at epoch 
>>> 3 from the client. Now the spirit of the rule in the text applies to epoch 
>>> 1 and the server can close the epoch (after optionally waiting a spell for 
>>> reordering)
>>
>>
>> Ah right, Nick Harper points out that servers really should close read epoch 
>> 1 [up to a delay to accommodate reordering] as soon as they receive the 
>> Finished message (epoch 2) and complete the handshake, not wait for an epoch 
>> 3 record. (But it must specifically be on handshake completion, not any 
>> epoch 2 record. Record-layer only logic cannot assume 1 < 2 because 2 might 
>> contain pre-Finished ACKs.)
>>
>> All this is missing from the specification. :-) I think we need to rewrite 
>> the spec text on epochs to more explicitly discuss their lifetimes.
>>
>>>
>>> So the rule is actually that we close according to a partially ordered set:
>>> - 0 (unencrypted) < 2 (handshake) < 3 (first app data) < 4 < 5 < ...
>>> - 1 (early data) < 3 (first app data) < 4 < 5 < ...
>>> - 1 is not ordered relative to 0 and 2.
>>>
>>>
>>> On Wed, Sep 18, 2024 at 3:47 PM David Benjamin  wrote:

 One more wriggle if we wish to allow unencrypted ACKs, though it is 
 fixable. Section 7, says:

 > During the handshake, ACK records MUST be sent with an epoch which is 
 > equal to or higher than the record which is being acknowledged. [...] 
 > Implementations SHOULD simply use the highest current sending epoch, 
 > which will generally be the highest available. After the handshake, 
 > implementations MUST use the highest available sending epoch.

 Taken at face value, that text implies that a client sending 0-RTT data 
 should send its ACKs at the highest current sending epoch, epoch 1 
 (0-RTT). But if the server has rejected

[TLS] Re: Publication has been requested for draft-ietf-tls-svcb-ech-05

[Sean Turner]

> On Sep 23, 2024, at 16:50, Sean Turner via Datatracker  
> wrote:
> 
> Sean Turner has requested publication of draft-ietf-tls-svcb-ech-05 as 
> Proposed Standard on behalf of the TLS working group.
> 
> Please verify the document's state at 
> https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/

Hi! Please note that we have requested the IESG publish this I-D along with the 
ECH I-D. We are forwarding this I-D to the AD without sending it to through the 
FATT because ECH has already undergone formal analysis; see Joe’s msg to the 
list [1].

Cheers,
spt

[1] https://mailarchive.ietf.org/arch/msg/tls/NvePkO_eeWEmkw8gksqlZBRFSSI/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Publication has been requested for draft-ietf-tls-svcb-ech-05

[Sean Turner via Datatracker]

Sean Turner has requested publication of draft-ietf-tls-svcb-ech-05 as Proposed 
Standard on behalf of the TLS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/


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

[TLS] Re: TLS WG Virtual Interim on FATT Process

[Sean Turner]

Hi! Thanks to all those who have already filled out the poll. I am hoping to 
close this out by Friday so I will send daily reminders until then.

Cheers,
spt

> On Sep 23, 2024, at 12:05, Sean Turner  wrote:
> 
> The chairs would like to have an interim to review the FATT (Formal Analysis 
> Triage Team) process. We are still working out the proposal, but we would 
> like to get this meeting scheduled to review any feedback / comments once we 
> do post the process. Please fill out the following with your available times 
> if you are interested in attending:
> 
> https://doodle.com/meeting/participate/id/aMoXAp1d
> 
> Thanks,
> Deirdre, Joe, & Sean

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

[TLS] ECH to the IESG

[Joseph Salowey]

We have requested the IESG publish ECH.  The ECH protocol has undergone
formal analysis to verify its security and privacy properties.  The
analysis referenced in the document is
https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf.
___
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

[Joseph Salowey]

There is rough consensus that the document should have additional formal
analysis before publication. Ekr proposed the following for the
authentication property, which seems like a reasonable clarification

"I think the right analysis is one in which the attacker knows the PSK. For
instance, say we have a company where everyone shares a PSK (as some kind
of post-quantum protection) and you want to make sure employee A cannot
impersonate employee B."

At this point it is up to the authors and working group to address the
request for additional symbolic analysis in order to move the document
forward.

The consensus call also indicated that there is a need to continue to work
out the process for formal analysis triage which we are working on as a
separate topic. See interim scheduling poll from Sean.

On Fri, Aug 23, 2024 at 10:30 AM Joseph Salowey  wrote:

> In regard to moving RFC 8773 to standards track the formal analysis triage
> group has provided input on the need for formal analysis which was posted
> to the list [1].  The authors have published a revision of the draft [2] to
> address some of this feedback, however the general sentiment of the triage
> panel was that there should be some additional symbolic analysis done to
> verify the security properties of the draft and to verify there is no
> negative impact on TLS 1.3 security properties.
>
> The formal analysis is to verify the following properties of the proposal
> in the draft:
>
> - The properties of the handshake defined in Appendix E.1 of RFC8446 [3]
> remain intact if either the external PSK is not compromised or (EC)DH is
> unbroken.
> - The public key certificate authentication works as in TLS 1.3, and this
> extension adds the condition that the party has possession of the external
> PSK. The details of external PSK distribution are outside the scope of this
> extension.
>
> This is a consensus call for the working group to determine how to proceed
> between these two options:
>
> 1. Require formal analysis in the symbolic model to verify that the
> proposal in the document does not negatively impact the security properties
> of base TLS 1.3 and that the additional security properties cited above are
> met
> 2. Proceed with publishing the document without additional formal
> verification
>
> Please respond to the list with a brief reason why you think the document
> requires formal analysis or not. This call will end on September 16, 2024.
>
> Thanks
>
> Joe, Deirdre, and Sean
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/
> [2]
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-8773bis-00&url2=draft-ietf-tls-8773bis-02&difftype=--html
> [3] https://www.rfc-editor.org/rfc/rfc8446.html#appendix-E.1
>
___
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

[David Benjamin]

For my neck of the woods, DTLS matters for WebRTC. It really should be
QUIC, but alas it isn't and I suspect redesigning all of WebRTC now atop
QUIC and then fully completing the transition would take much longer than
getting to DTLS 1.3, much as the DTLS 1.3 specification needs a -bis
document. :-)

On Mon, Sep 23, 2024 at 6:10 PM Watson Ladd  wrote:

> Backing up a bit, at what point do we say QUIC Datagram is the right
> way to do this?
>
> This whole adventure sounds like a mess.
>
> On Fri, Sep 20, 2024 at 8:20 AM David Benjamin 
> wrote:
> >
> > (Resending since I don't see these two mails in the list archives, so
> I'm not sure if the list software broke again. Apologies if this is a
> duplicate mail!)
> >
> > On Thu, Sep 19, 2024 at 1:49 PM David Benjamin 
> wrote:
> >>
> >> On Thu, Sep 19, 2024 at 1:31 PM David Benjamin 
> wrote:
> >>>
> >>> Ah fun, another issue in this document. So not only are write epoch
> lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes are
> specified but wrong.
> >>>
> >>> Section 4.2.1 says:
> >>>
> >>> > Because DTLS records could be reordered, a record from epoch M may
> be received after epoch N (where N > M) has begun. Implementations SHOULD
> discard records from earlier epochs but MAY choose to retain keying
> material from previous epochs for up to the default MSL specified for TCP
> [RFC0793] to allow for packet reordering. (Note that the intention here is
> that implementers use the current guidance from the IETF for MSL, as
> specified in [RFC0793] or successors, not that they attempt to interrogate
> the MSL that the system TCP stack is using.)
> >>>
> >>> https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1
> >>>
> >>> First, it's a bit weird to say you SHOULD discard records but MAY
> retain keying material. I assume that meant SHOULD discard records but MAY
> process records anyway up to MSL. Anyway, this model implies that only one
> read epoch is active at once, but this isn't true. You basically have to
> read epoch 1 (early data) as unordered relative to epoches 0 and 2.
> Consider a DTLS 1.3 server:
> >>>
> >>> 1. The server reads ClientHello with early_data extension at epoch 0
> and accepts early data.
> >>> 2. The server sends ServerHello (epoch 0), EE..Finished (epoch 2), and
> activates write epoch 3 for half-RTT application data.
> >>> 3. The server reads early data (epoch 1) from the client. The RFC
> would lead you to think the server can close read epoch 0 now, but...
> >>> 4. ServerHello gets lost and, if we are to believe
> https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8, the client
> might send an empty plaintext ACK to trigger a retransmit. This ACK will be
> at epoch 0. This only works if the server keeps read epoch 0 open!
> >>> 5. Client eventually gets the ServerHello but now it only gets half of
> the epoch 2 data. It sends an ACK to trigger another retransmit. This ACK
> will come at epoch 2.
> >>> 6. Server receives that ACK at epoch 2 and retransmits. The RFC would
> lead you to think the server can close read epoch 1 now, but...
> >>> 7. Let's say that retransmit is lost again, or hasn't arrived yet.
> From the client's perspective, it has a connection that has yet to reach
> the 1-RTT point, so any data from the calling application will still be
> sent as early data. That means the client will continue to send early data
> at epoch 1. This only works if the server keeps read epoch 1 open!
> >>> 8. The handshake progresses and the server finally gets 1-RTT data at
> epoch 3 from the client. Now the spirit of the rule in the text applies to
> epoch 1 and the server can close the epoch (after optionally waiting a
> spell for reordering)
> >>
> >>
> >> Ah right, Nick Harper points out that servers really should close read
> epoch 1 [up to a delay to accommodate reordering] as soon as they receive
> the Finished message (epoch 2) and complete the handshake, not wait for an
> epoch 3 record. (But it must specifically be on handshake completion, not
> any epoch 2 record. Record-layer only logic cannot assume 1 < 2 because 2
> might contain pre-Finished ACKs.)
> >>
> >> All this is missing from the specification. :-) I think we need to
> rewrite the spec text on epochs to more explicitly discuss their lifetimes.
> >>
> >>>
> >>> So the rule is actually that we close according to a partially ordered
> set:
> >>> - 0 (unencrypted) < 2 (handshake) < 3 (first app data) < 4 < 5 < ...
> >>> - 1 (early data) < 3 (first app data) < 4 < 5 < ...
> >>> - 1 is not ordered relative to 0 and 2.
> >>>
> >>>
> >>> On Wed, Sep 18, 2024 at 3:47 PM David Benjamin 
> wrote:
> 
>  One more wriggle if we wish to allow unencrypted ACKs, though it is
> fixable. Section 7, says:
> 
>  > During the handshake, ACK records MUST be sent with an epoch which
> is equal to or higher than the record which is being acknowledged. [...]
> Implementations SHOULD simply use the highest current sending epoch, which
> will gen

[TLS] Re: DTLS 1.3 and the 0-RTT <-> 1-RTT transition

[David Benjamin]

To add to the list of issues, DTLS 1.3 says very little about 0-RTT, but
skipping early data is very different between TLS and DTLS. In particular,
I think Appendix D.3 just doesn't apply to DTLS 1.3. DTLS 1.2
implementations were already expected to discard bad packets, so they'll
naturally skip over early data. So rather than the text in D.3, I think we
just say that you treat a DTLS 1.2 ServerHello as an implicit 0-RTT reject
and continue on.

On Wed, Sep 18, 2024 at 4:13 PM David Benjamin 
wrote:

> Another issue with RFC 9147: when does the client switch from sending
> 0-RTT to 1-RTT app data, and when does the server start processing 1-RTT
> app data from the client?
>
> This is less of an open question (I think we match how we already resolved
> this for QUIC), but is something we should have written down, so consider
> this yet another reason we need rfc9147bis.
>
> Presumably, the client starts sending 1-RTT data, and stops sending 0-RTT
> data, as soon as it has sent out its Finished message. This matches other
> handshake flows, and also avoids the calling application getting confused
> about continuing to send early data after the handshake is reported as
> completed.
>
> But then that begs the opposite question: does the server install the
> 1-RTT read keys before or after it receives client Finished? If before,
> it's honestly fine (the AEAD tag does the same thing), but it breaks
> assumptions made in TLS analysis. If after, there is an awkward hiccup in
> the server's ability to receive data from the client, if the Finished
> packet is lost.
>
> For QUIC, we ended up deciding:
> - You do not decrypt 1-RTT records until you've received/sent enough to
> finish the handshake.
> - There is a head-of-line blocking problem at the transition point.
> - Clients can mitigate this by eagerly packing the Finished with their app
> data until they get an ACK.
> https://www.rfc-editor.org/rfc/rfc9001.html#section-5.7
>
> TBH, I doubt anyone will actually do the last one. (We are not currently
> planning to implement 0-RTT for DTLS at all, unless it ends up being an
> easy extra thing.) But I think this is worth writing down explicitly. The
> exact timings of key transitions are much more visible to DTLS and QUIC
> than they are to TLS, so I think this is worth being explicit about.
>
> David
>
___
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

[Russ Housley]

I agree, and I think the Security Considerations already cover this point:

   If the external PSK is known to any party other than the client and
   the server, then the external PSK MUST NOT be the sole basis for
   authentication.  The reasoning is explained in Section 4.2 of
   [K2016].  When this extension is used, authentication is based on
   certificates, not the external PSK.

Russ

> On Sep 23, 2024, at 4:49 PM, Joseph Salowey  wrote:
> 
> There is rough consensus that the document should have additional formal 
> analysis before publication. Ekr proposed the following for the 
> authentication property, which seems like a reasonable clarification
> 
> "I think the right analysis is one in which the attacker knows the PSK. For 
> instance, say we have a company where everyone shares a PSK (as some kind of 
> post-quantum protection) and you want to make sure employee A cannot 
> impersonate employee B."
> 
> At this point it is up to the authors and working group to address the 
> request for additional symbolic analysis in order to move the document 
> forward.
> 
> The consensus call also indicated that there is a need to continue to work 
> out the process for formal analysis triage which we are working on as a 
> separate topic. See interim scheduling poll from Sean. 
> 
> On Fri, Aug 23, 2024 at 10:30 AM Joseph Salowey  > wrote:
>> In regard to moving RFC 8773 to standards track the formal analysis triage 
>> group has provided input on the need for formal analysis which was posted to 
>> the list [1].  The authors have published a revision of the draft [2] to 
>> address some of this feedback, however the general sentiment of the triage 
>> panel was that there should be some additional symbolic analysis done to 
>> verify the security properties of the draft and to verify there is no 
>> negative impact on TLS 1.3 security properties.
>> 
>> The formal analysis is to verify the following properties of the proposal in 
>> the draft:
>> 
>> - The properties of the handshake defined in Appendix E.1 of RFC8446 [3] 
>> remain intact if either the external PSK is not compromised or (EC)DH is 
>> unbroken.
>> - The public key certificate authentication works as in TLS 1.3, and this 
>> extension adds the condition that the party has possession of the external 
>> PSK. The details of external PSK distribution are outside the scope of this 
>> extension.
>> 
>> This is a consensus call for the working group to determine how to proceed 
>> between these two options:
>> 
>> 1. Require formal analysis in the symbolic model to verify that the proposal 
>> in the document does not negatively impact the security properties of base 
>> TLS 1.3 and that the additional security properties cited above are met
>> 2. Proceed with publishing the document without additional formal 
>> verification
>> 
>> Please respond to the list with a brief reason why you think the document 
>> requires formal analysis or not. This call will end on September 16, 2024.
>> 
>> Thanks
>> 
>> Joe, Deirdre, and Sean
>> 
>> [1] https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/
>> [2] 
>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-8773bis-00&url2=draft-ietf-tls-8773bis-02&difftype=--html
>> [3] https://www.rfc-editor.org/rfc/rfc8446.html#appendix-E.1
> ___
> 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