[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
On Fri, 23 Aug 2024, 19:30 Joseph Salowey, wrote: > 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. > What's the goal? Security guarantees: Do the work. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel
On Sun, 2 Jun 2024, 19:17 Russ Housley, wrote: > EKR: > > I agree with most of your points about the process, but I want to respond > to this paragraph in particular. > > Similarly here, if the WG feels that a change is sufficiently large to > require formal analysis then the WG -- and more specifically those who > want the work to move forward -- need to figure out how to get that > analysis done, though of course the triage panel or the broader > community might help facilitate if there is enough demand or interest > in the work. > > > There was no consensus call by the WG Chairs. During WG Last Call, a few > people asked for formal analysis, but others felt that the informal > analysis in the document was good enough. > > I realize that we are quite purposefully embracing formal analysis. It is > a good thing. The number of people that have experience with the tools is > very small. If this is going to be successful enough to expand to other > protocols, then we need to find ways to expand the size of this group. > The group is probably large enough? > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
Re: [TLS] [EXT] Re: Time to first byte vs time to last byte
> Given that especially for the web, CDNs used much higher initcwnds, > > Please, let us not assume every website is behind a CDN. > > Isn't that assumption reasonable? At least for global websites --- without > CDN performance sucks. > > *Of course* it isn’t. > As a reference point: Consider reading the New York Times in Canberra, doesn't happen without CDN #SpeedOfLightSlow ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Time to first byte vs time to last byte
On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan wrote: > Given that especially for the web, CDNs used much higher initcwnds, > > > Please, let us not assume every website is behind a CDN. > Isn't that assumption reasonable? At least for global websites --- without CDN performance sucks. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] errata (was Re: Late holiday gifts)
On Tue, 23 Jan 2024 at 20:47, Salz, Rich wrote: > > The TLS WG holds the distinction for have the most reported errata (61) > [0]. We need to start working through these at some point. > > This spreadsheet is probably more useful for people who want to help out, > since only the ADs can really make conclusions as I understand it. (Errata > process doesn't seem to be documented; I'll post to RSWG about that) > > https://docs.google.com/spreadsheets/d/1nmuRTV0Fwx-p13AMSV5GMZP5QCn80K0T5Oht5d8Putw/edit#gid=133722335 > > The green color-coding means someone updated the item, IIRC, but I don't > remember the details. > Many of the TLS (RFC 8446) issues have been worked through and resolved in https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (7620)
> > >> > My point is that the relevant semantics here are application semantics, > not TLS semantics. > > Regardless of what TLS says, nothing stops an application protocol from > allowing A to decide it doesn't care what B has to say and sending > close_notify then closing the transport connection. At this point, whatever > the B does is irrelevant because A isn't listening. > Agree. TLS 1.2 imposed full close semantics. > Agree. What TLS 1.3 does is allow applications to choose *either* full close or > half close semantics, > (That is unclear to me from RFC 8446.) but doesn't have a TLS-level signal of which one the application wants. So, > the application can either have: > > - Once the other side sends close_notify, just stop sending ASAP (full > close) > - Once the other side sends close_notify, don't expect anything else, but > send what you want to send (half close). > TLS implementations with full close don't provide high-level applications with such choice (e.g., Bouncy Castle) whilst implementations with half close do (e.g., OpenJDK). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (7620)
On Sat, 2 Sept 2023, 13:30 Ben Smyth, wrote: > RFC8446 leans towards half closure but doesn't mandate it. > > [For full closure,] it makes sense for A to just flush the outgoing data >> > > Yes. > > [For half closure], we want A to continue sending and then eventually send >> a close_notify when it has drained its queue. >> > But this suggests that we can't have a one size fits all rule in TLS and >> rather should explain the situation and punt it to the application binding. >> > > Why is this suggested? > Oh, perhaps: Because RFC8446 doesn't mandate half closure, implementations could either transmit all data and close write, or just close inbound? > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (7620)
Variant of your example: A receives a request, buffers M1,..., M5, receives close_notify after sending M4; A's peer sent the request before closing their write side. Half closure supports request-then-close. (Related thread in archive: https://mailarchive.ietf.org/arch/msg/tls/V47DfS4qdsdrF2QLHogsw_aNp9M/.) Suppose the response is a wire transfer instruction with M4||M5 being "Charlie||'s Angels". With full closure the attacker's goal is to delay close_notify such that M5 is dropped. On Thu, 31 Aug 2023, 17:48 Eric Rescorla, wrote: > Have I missed something? > I think we're on the same page. it seems to me that this is actually a somewhat complicated question that > is about application semantics more than about TLS itself. Specifically, > what sementics does the application think the close_notify embodies, half > close or full close? > RFC8446 leans towards half closure but doesn't mandate it. [For full closure,] it makes sense for A to just flush the outgoing data > Yes. [For half closure], we want A to continue sending and then eventually send > a close_notify when it has drained its queue. > But this suggests that we can't have a one size fits all rule in TLS and > rather should explain the situation and punt it to the application binding. > Why is this suggested? > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (7620)
On Tue, 29 Aug 2023, 14:31 Eric Rescorla, wrote: > On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth wrote: > >> On Mon, 28 Aug 2023, Eric Rescorla, wrote: >> >>> ...there are quite a few situations in which endpoints close the >>>>> connection before receiving a close_notify, for instance, when they >>>>> receive >>>>> an end of data message in the application protocol or when they time out. >>>>> The former case is generally safe, the latter is not, but extremely >>>>> common, in fact perhaps the dominant caseI'm not sure this is an >>>>> erratum as I think it correctly describes the situation and it's a >>>>> judgement call whether we ought to have a requirement here or whether it's >>>>> a 6919 MUST (BUT WE KNOW YOU WON'T) >>>>> >>>> >> TLS 1.2 dictates: Either party may initiate a close by sending a >> close_notify alert...The other party MUST respond with a close_notify alert >> of its own and close down the connection immediately, discarding any >> pending writes. >> >> RFC 8446-bis could simply forbid that behaviour, e.g., This does not have >> any effect on the read side of the sender's connection; a party receiving a >> "close_notify" alert MUST NOT respond with a "close_notify" alert of its >> own. Note that this is a change from versions of TLS prior to TLS 1.3 in >> which receivers were required to react to a "close_notify" by discarding >> pending writes and sending an immediate "close_notify" alert of their own. >> > > I must be missing something, as I don't see how that would help. Perhaps > you could provide an example of what it is you are concerned about? > Sure: As-is the specification doesn't mandate against the old behaviour; a specification compliant implementation may be vulnerable to the TLS 1.2 truncation attack arising from closure in both directions. Whilst I appreciate the issues raised in this thread, I believe the specification could be stricter by mandating against the old behaviour. As-is, hints are raised, guidance given, but there's no strict requirement. Perhaps I'm just reading too rigorously, there's no need to formally forbid---as an IETF outsider, that seems a little lax, I'd expect a change from two-way closure to one-way closure to be mandated, thereby explicitly teaching away from a known vulnerability. RFC8446-bis is an opportunity to polish the original spec. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (7620)
On Mon, 28 Aug 2023, Eric Rescorla, wrote: > ...there are quite a few situations in which endpoints close the >>> connection before receiving a close_notify, for instance, when they receive >>> an end of data message in the application protocol or when they time out. >>> The former case is generally safe, the latter is not, but extremely >>> common, in fact perhaps the dominant caseI'm not sure this is an >>> erratum as I think it correctly describes the situation and it's a >>> judgement call whether we ought to have a requirement here or whether it's >>> a 6919 MUST (BUT WE KNOW YOU WON'T) >>> >> TLS 1.2 dictates: Either party may initiate a close by sending a close_notify alert...The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. RFC 8446-bis could simply forbid that behaviour, e.g., This does not have any effect on the read side of the sender's connection; a party receiving a "close_notify" alert MUST NOT respond with a "close_notify" alert of its own. Note that this is a change from versions of TLS prior to TLS 1.3 in which receivers were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (7620)
Yes, we agree. I anticipate necessity to reduce the strength my wording (or to ignore). I raise this errata only to discuss specification-compliant implementations being vulnerable to truncation attack; it'd surely be better to have a SHOULD or SHOULD NOT. On Mon, 28 Aug 2023, 14:43 Eric Rescorla, wrote: > Hi Ben, > > Before addressing the text, let's make sure we are on the same page about > the situation. > > As you probably know, there are quite a few situations in which endpoints > close the connection before > receiving a close_notify, for instance, when they receive an end of data > message in the application > protocol or when they time out. The former case is generally safe, the > latter is not, but extremely > common, in fact perhaps the dominant case. Do we agree on that? > > -Ekr > > > On Mon, Aug 28, 2023 at 4:02 AM RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8446, >> "The Transport Layer Security (TLS) Protocol Version 1.3". >> >> -- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7620 >> >> -- >> Type: Technical >> Reported by: Ben Smyth >> >> Section: 6.1 >> >> Original Text >> - >> Each party MUST send a "close_notify" alert before closing its write >> side of the connection, unless it has already sent some error alert. >> This does not have any effect on its read side of the connection. >> Note that this is a change from versions of TLS prior to TLS 1.3 in >> which implementations were required to react to a "close_notify" by >> discarding pending writes and sending an immediate "close_notify" >> alert of their own. That previous requirement could cause truncation >> in the read side. Both parties need not wait to receive a >> "close_notify" alert before closing their read side of the >> connection, though doing so would introduce the possibility of >> truncation. >> >> Corrected Text >> -- >> Each party MUST send a "close_notify" alert before closing its write >> side of the connection, unless it has already sent some error alert. >> This SHOULD NOT have any effect on the read side of the sender's >> connection; >> parties SHOULD receive a "close_notify" alert before closing the read >> side of their connection. >> Note that this is a change from versions of TLS prior to TLS 1.3 in >> which receivers were required to react to a "close_notify" by >> discarding pending writes and sending an immediate "close_notify" >> alert of their own. That previous requirement could cause truncation >> in the read side. Both parties need not wait to receive a >> "close_notify" alert before closing their read side of the >> connection, though doing so would introduce the possibility of >> truncation. >> >> Notes >> - >> As-is there's a specification-level vulnerability: >> Specification-compliant implementations may be vulnerable to truncation >> attacks. >> >> I suggest using SHOULD NOT & SHOULD for better signposting and to avoid >> specification-level vulnerability. >> >> I also suggest minor tweaks for readability. >> >> Instructions: >> - >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -- >> RFC8446 (draft-ietf-tls-tls13-28) >> -- >> Title : The Transport Layer Security (TLS) Protocol Version >> 1.3 >> Publication Date: August 2018 >> Author(s) : E. Rescorla >> Category: PROPOSED STANDARD >> Source : Transport Layer Security >> Area: Security >> Stream : IETF >> Verifying Party : IESG >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
On Wed, 12 Apr 2023, 03:18 Peter Gutmann, wrote: > On the subject of clarification, the update also needs to explain why PSK > is > split across two separate extensions, psk_key_exchange_modes and > pre_shared_key Because pre_shared_key appears in ClientHello and ServerHello, whilst psk_key_exchange_modes only appears in the former? > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Profile ID in CTLSServerPlaintext
On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak wrote: > ...how will an endpoint correctly distinguish between multiple, CID-ext-based CTLSClientPlaintext requests and CTLSServerPlaintext responses when the same socket is used for client and server communication. On Wed, 4 Jan 2023 at 15:29, Ben Schwartz wrote: > cases where (1) a single 5-tuple can be used for DTLS in both directions, (2) the parties have not already agreed who will be the client and who will be the server, and (3) there can be multiple handshakes in flight simultaneously. In this case, a party who sends a ClientHello might receive a ServerHello, HRR, or a racing ClientHello in response. This is not a use case I had thought about. Is this considered a supported configuration for DTLS (with Connection IDs)? On Wed, 4 Jan 2023 at 17:10, Eric Rescorla wrote: > When would this actually happen? Assuming this could happen, then the RFC should surely mention the possibility, and perhaps be reworked to avoid raising an error. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What is "completed handshake"?
On Tue, 9 Aug 2022 at 08:50, Martin Thomson wrote: > On Tue, Aug 9, 2022, at 16:36, Ben Smyth wrote: > > On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote: > >> "Upon receiving the server's messages, the client responds with its > Authentication messages, namely Certificate and CertificateVerify (if > requested), and Finished. At this point, the handshake is complete" > > > > I stumbled with this. > > That seems clear enough to me. At least from the client's perspective. > Presumably the server has to receive the client's Finished to consider the > handshake complete. > For me there was a eureka! moment, when I finally understood, suddenly everything fell into place. It could have been an easier journey; I don't know whether I can better explain. There are handshake messages, there's handshaking, and there's handshake completion. Handshaking is an exchange of handshake messages. Handshake messages are also exchanged post handshake completion. A handshake partially completes on sending/receiving a server's Finished message---a server can send application data thereafter---an authenticated channel from the server to a client is established. A handshake fully completes on sending/receiving the client's (first) Finished message, a channel (optionally, authenticated) from the client to the server is established. Post-handshake authentication adds a twist, further client Finished messages may be sent/received. >From the above, we see two points at which the handshake completes, and a further two points of partial completion. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What is "completed handshake"?
On Mon, Aug 8, 2022 at 4:19 PM Dmitry Belyavsky wrote: > RFC 8446 refers to "completed handshake" as a prerequisite for some messages. But looking for the word "completed", I don't see any definition. On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote: > "Upon receiving the server's messages, the client responds with its Authentication messages, namely Certificate and CertificateVerify (if requested), and Finished. At this point, the handshake is complete" I stumbled with this. OpenJDK reports handshake completion twice [1,2]. Anthony Scarpino explains: "SSLEngine with post handshake messages returns HandshakeStatus.FINISHED [more than once]...Before TLS 1.3 and PostHandshake messages, the usage for FINISHED was clearly only during the handshake process and more tied to the [TLS] Finished message [Since TLS 1.3,] KeyUpdate and NewSessionTicket call finishPostHandshake() which sets the handshake status" [3]. The specification would benefit from some extra clarification. [1] https://mail.openjdk.org/pipermail/security-dev/2022-May/030784.html [2] https://mail.openjdk.org/pipermail/security-dev/2022-June/031019.html [3] https://mail.openjdk.org/pipermail/security-dev/2022-June/031044.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] KeyUpdate.update_requested when outbound is closed
Message KeyUpdate may include update_requested after a receiver has sent a close_notify alert. Maybe the sender never received the alert. Maybe the sender anyhow requested. The receiver is mandated to send a KeyUpdate of its own, but obviously won't. Is any special care needed in this situation? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Authentication weaker in PSK-mode?
Authentication feels weaker in PSK-mode: * A server proves possession of a (short-term) shared key, whereas, with certificate-based authentication, * A server proves possession of a (long-term) private key; should we consider PSK-mode authentication weaker than certificate-based authentication? PSK-mode cannot be bolstered with certificate-based authentication: "In TLS 1.3...either a PSK or a certificate is always used, but not both. Future documents may define how to use them together." Have any such documents emerged? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 clarification request
On Wed, 17 Mar 2021, 15:31 Jeremy Harris, wrote: > On 17/03/2021 07:15, Ben Smyth wrote: > > Perhaps one scenario where that > > behaviour is useful: An endpoint is about to be comprimised and raises an > > alert to avoid secrets being leaked. > > I'd have tout that a section 6.2 Error Alert would be more > appropriate in such a situation, than the (implicitly > non-error) section 6.1 Closure Alert I'm discussing. > > Do you at least agree that Google is in violation of the 6.1 > wording requiring that it sends a Close Alert before sending > a TCP FIN? > Which aspect of Section 6.1 do you think Google doesn't comply with? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 clarification request
On Tue, 16 Mar 2021, 20:03 Jeremy Harris, wrote: > On 16/03/2021 07:53, Ben Smyth wrote: > > Further, is it reasonable for the above first end to > >> expect the above second end to continue processing and > >> sending data that would have been sent in the absence of > >> such a first Close Alert? > >> > > > > The endpoint should expect their interlocutor to ignore any data received > > after the alert: Any data received after a closure alert has been > received > > MUST be ignored. > > > > The endpoint should expect any data sent before raising alert > close_notify > > to be delivered: It is assumed that closing the write side of a > connection > > reliably delivers pending data before destroying the transport. > > > > Whether an interlocutor processes data sent before alert close_notify is > > seemingly not governed by the specification, which seems reasonable. > > So, that doesn't directly answer that portion of my question - but > does appear to make a half-close useless, by requiring an end > to hold off sending a Close alert until after if has received all > data that the far end is expected to send. > > Do I understand that right? And if so, what is the point of the > language in the RFC that appears to permit a half-close? Specifications don't define systems, they guide design. The specification does not "requir[e] an end to hold off sending a Close alert until after if has received all data that the far end is expected to send," the specification merely allows such behaviour. Perhaps one scenario where that behaviour is useful: An endpoint is about to be comprimised and raises an alert to avoid secrets being leaked. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 clarification request
On Mon, 15 Mar 2021 at 11:52, Jeremy Harris wrote: > Could people please confirm a detail of TLS 1.3 session > close behaviour? Specifically, are half-closes supported > in similar fashion to TCP half-closes - in that it is > legitimate for one end to issue a Close Notify alert > and for the other end to receive that alert but continue > to transmit data after such reception and before sending > its own Close Notify? > This seems like expected behaviour: An endpoint has finished using an outbound connection and raises alert close_notify (Section 6.1): This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored. The text goes one: This [close_notify alert] does not have any effect on its read side of the connection. The endpoint may continue receiving on an inbound connection. Further, is it reasonable for the above first end to > expect the above second end to continue processing and > sending data that would have been sent in the absence of > such a first Close Alert? > The endpoint should expect their interlocutor to ignore any data received after the alert: Any data received after a closure alert has been received MUST be ignored. The endpoint should expect any data sent before raising alert close_notify to be delivered: It is assumed that closing the write side of a connection reliably delivers pending data before destroying the transport. Whether an interlocutor processes data sent before alert close_notify is seemingly not governed by the specification, which seems reasonable. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-rfc8446bis - Security propterites - Protection of endpoint identities
On Wed, 10 Feb 2021 at 12:09, Ben Smyth wrote: > On Wed, 10 Feb 2021, 10:19 John Mattsson, 40ericsson@dmarc.ietf.org> wrote: > >> I think RFC8446bis needs to state that this property only holds for >> cipher suites with confidentiality. >> > > All cipher suites defined by RFC8446bis (Appendix B.4) provide > confidentiality. The property always holds. > Given that Appendix C.5 discusses unauthenticated cipher suites, perhaps Appendix B.4 could be extended as follows: Previous versions of TLS explicitly offered a null cipher (wherein encryption consists of the identity operation, i.e., the data is not encrypted). These modes have been deprecated in TLS 1.3. (At least, that's my understanding.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-rfc8446bis - Security propterites - Protection of endpoint identities
On Wed, 10 Feb 2021, 10:19 John Mattsson, wrote: > I think RFC8446bis needs to state that this property only holds for cipher > suites with confidentiality. > All cipher suites defined by RFC8446bis (Appendix B.4) provide confidentiality. The property always holds. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 Authentication and Integrity only Cipher Suites
Internet-Draft "TLS 1.3 Authentication and Integrity only Cipher Suites" ( https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-08) highlights TLS use cases with authentication and integrity needs, without any need for confidentiality. The draft promotes mutual authentication, but this seems unnecessary, as I'll discuss. I'm also unclear why certificate-based authentication is mandated, as I'll also discuss. Let me first summarise application scenarios. The need to couple authentication and integrity seems clear: Neither makes sense without the other. (There's little sense in authenticating an interlocutor, without knowing whether they are communicating thereafter.) Equally, the case for dropping confidentiality seems clear: Some applications, including use cases given, simply do not require confidentiality. (It's worth noting that traffic analysis can anyhow defeat confidentiality, albeit, I'm unsure of the specifics.) The need for mutual authentication is unclear to me and seemingly unsubstantiated by use cases. For example, in the weather reporting use case, only the weather reporter need authenticate, a node seeking the report need not. Although some use cases may require mutual authentication, others seemingly do not. Given that unilateral authentication reduces computational and communication burden, whilst eradicating a class of private keys, can the draft be generalised to permit unilateral or mutual authentication? Actually, as it stands, the draft does not appear to provide mutual authentication, since TLS only provides unilateral authentication of a server by default. To ensure mutual authentication, the draft must mandate a server sending a CertificateRequest message, and a client responding with Certificate and CertificateVerify messages (rather than merely a Certificate message that does not contain a certificate). (For PSK-based key exchange, a client must include extension post_handshake_auth in their ClientHello message and a server must send a CertificateRequest after the handshake completes, but this mode isn't currently supported by the draft.) The draft mandates that "PSK data MUST NOT be sent in the handshake [due to the lack of confidentiality]," yet a standard ClientHello message sends PSK data (listing pre-shared key identifiers and key exchange modes for each) in the clear, as does a standard ServerHello message (a server-selected identifier is included). It's only a standard EncryptedExtensions message that protects handshake data, yet I can't find any PSK data that would be protected. Is PSK-based authentication viable? (I suspect a server could even securely issue a NewSessionTicket message, since such messages don't contain any particularly sensitive information, perhaps with the exception of the ticket_nonce, but even that shouldn't be sensitive, given that it merely ensures distinct pre-shared keys. That said, I haven't thought through the details.) I appreciate the work by Nancy and Jack on this draft, which covers useful application scenarios beyond the scope of the TLS 1.3 specification. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"
Dear Joe, On Sat, 16 Jan 2021 at 21:29, Joseph Salowey wrote: > We've only had one review in response to the last call so far, I'd like > to see a few more reviews of this document before moving it forward. Are > there any volunteers who can commit to a review in the near future? > I've reviewed and have only a handful of minor comments. Section 1, opening: Password and key comparison seems rather weak, unless low-entropy PSKs are used. If low-entropy PSKs are a focus, then perhaps make this clearer, which will simultaneously strengthen the comparison. Section 4, "These keys do not provide protection of endpoint identities (see Section 5), nor do they provide non-repudiation (one endpoint in a connection can deny the conversation)": Perhaps relate to other modes of TLS which do provide such protection. Section 4, "If this assumption is violated": The assumption has two aspects, namely, "each PSK is known to exactly one client and one server" and "these never switch roles." The following paragraph explains what happens if each PSK is known to more than one client, server, or both. But what if roles are switched? Whilst maintaining the former aspect of the assumption. Section 4, "then the security properties of TLS are severely weakened": Perhaps add "as explained below" or similar. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 8879 on TLS Certificate Compression
On Wed, 2 Dec 2020 at 08:32, wrote: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. > Round trips are only mentioned in the abstract. It's perhaps worth mentioning when round trips are saved: When a certificate chain would exceed a client's receive window or a server's congestion window. Servers have no control over receive windows, so round trips can only be avoided by reducing certfication chain length. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Manual: Call for contributions
On Tue, 1 Dec 2020 at 12:09, Ben Smyth wrote: > I previously announced a TLS manual, intended to ease readers into the > most recent specification...I'm far from perfect and I'm sure the > manuscript houses numerous deficiencies. > Speaking of imperfections, I neglected to share a URL for a pre-compiled PDF: https://bensmyth.com/files/Smyth19-TLS-tutorial.pdf (Thanks to Chris for pointing that out.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS Manual: Call for contributions
I previously announced a TLS manual, intended to ease readers into the most recent specification. (At the very least, it helped me get to grips with the spec!) I've now made the manual available on GitHub: https://github.com/BenSmyth/tls-tutorial/ I'm far from perfect and I'm sure the manuscript houses numerous deficiencies. Interesting aspects are omitted, because I didn't have the time, knowledge, or expertise to add them. For instance, the specification hasn't been entirely covered, as is documented; discussion of security guarantees are notably lacking; and an introduction to the underlying cryptography is absent. (E.g., some details on DHKE, AEAD, etc. would be grand.) Directions for further exploration are missing, hands-on teaching opportunities foregone. For instance, a Davies-style exploration of TLS on-the-wire, with notes on Wireshark and SSLKEYLOGFILE---perhaps as dirty as readers can get, without bursting-out soldering irons. Mistakes and issues are no doubt numerous. I encourage you to improve this manuscript. Fix a typo. Patch grammar. Revise awkward, overcomplicated, or otherwise poorly-written passages. Contribute an entire section. Help evolve the manual. (Perhaps get in touch prior to writing an entire section! We should probably reach consensus on what to add.) Contributions will be recognised through acknowledgements or co-authorship. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
I haven't followed all the nuances of this discussion, but it seems to boil down to use of "MUST NOT" when certain "EXCEPTIONS MAY" exist for private enterprise running legacy kit, which makes decision makers anxious, since they don't want responsibility for something they "MUST NOT" do: A solution might be to introduce "MUST NOT...EXCEPTIONS MAY" language, thereby allowing sectors to define their standards/principles/expectations. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
Dear Michael, On Tue, 29 Sep 2020 at 17:14, Michael D'Errico wrote: > OK, so it sounds like you put something similar to a > NewSessionTicket (TLS 1.2) in the cookie with enough > information to recreate the server state. Whilst getting to grips with TLS 1.3, I wrote a tutorial (https://arxiv.org/abs/1904.02148), I think you might find it useful. For instance, I explain the cookie on page 19. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
The client will reject the server's ServerHello in your example. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-rescorla-tls-rfc8446-bis
I support adoption and I am willing to help work on this. (Eric has already incorporated many of my suggestions, many thanks for that.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
On Tue, 28 Jul 2020 at 10:35, Arnaud.Taddei.IETF wrote: > I strongly support this work as it represents capabilities that are being > developed, deployed and used in practice. It has good intentions and provides > a good approach in the context of defense in depth approaches. No security > cannot be just on both ends of the communication. One can dream about it but > that is not how reality is. I appreciate that capabilities are being developed, deployed, and used. However, shouldn't a secure solution be sought? Surely secure solutions are just waiting to be discovered? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Traffic secrets: What's in handshake transcripts?
As far as I can tell, secret [sender]_handshake_traffic_secret is computed over transcript CH || SH or CH || HRR || CH || SH. (A server can compute their secret once they've computed SH, whereas a client must wait until they've received SH before computing their secret.) Secret server_application_traffic_0 is computed over an extended transcript which additionally includes EE, (optionally) CR, (optionally) CT & CV, and FIN, and secret client_application_traffic_0 further extends that transcript to include (optionally) EndOfEarlyData, (optionally) CT, (optionally) CV, and FIN. Is that right? Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC8446 (6125)
Dear Peter, On Fri, 1 May 2020 at 12:30, Peter Wu wrote: > Do you have a specific sentence that caused confusion for you? Both > "out-of-band" and "external" can be used interchangeably. > Getting to grips with TLS 1.3 has been challenging for me! The use of synonyms made it more difficult. I hope that the reports I have submitted will aid others in understanding the specification. Longer-term they may even aid the development for future documents. Many of the reports are minor, others are preventing me from fully understanding the specification, and several may highlight minor technical issues. They all came about whilst writing a manual for TLS ( https://bensmyth.com/publications/2019-TLS-tutorial/), which I'm currently extending. Since the reports are based on my private notes, I thought sharing them (via reports) would be useful. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking
> > Section 4.2.10 requires a server receiving early data to behave in ways >> including (p53): >> >> * Ignore the extension and return a regular 1-RTT response. The server >> then skips past early data by attempting to deprotect received records >> using the handshake traffic key, discarding records which fail >> deprotection... >> >> * Request that the client send another ClientHello by responding with a >> HelloRetryRequest... The server then ignores early data by skipping all >> records with an external content type of "application_data"... >> >> What are the use cases for each behaviour? >> > I expect that the first response will be the ordinary one. However, in some > cases you will be forced to employ the second one because it is not > possible to send a SH. For instance, consider the case where the server has > been reconfigured and no longer accepts the DH group that the client > employs in the CH. In that case, it will have to send HRR. > SH and HRR are simply used in their usual ways: Thanks for the clarification. > And why does the former rely on deprotecting, when checking record content >> types is surely more efficient? >> > > Unfortunately, the record types are encrypted, and this will not work. > (I meant the external content type. But, that doesn't work anyhow.) I have now understood: When not consuming early data, respond with SH or HRR. For the former, given that all messages will be encrypted, the server must decrypt messages with the handshake traffic key, discard messages when decryption fails, and treat the first successfully decrypted message as the client's next handshake message, thereafter proceeding as if no early data were sent. For the latter, the second CH message will be unencrypted and the server can discard all encrypted messages (identified by record type 0x23, rather than 0x22), before proceeding as if no early data were sent when the second CH is identified. Thanks for your support, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 8446: Correlating connections with ticket ages
Section 4.2.11.1 explains that: PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add"... This addition prevents passive observers from correlating connections unless tickets are reused. So: Correlations are possible when tickets are reused. But, what connection correlations are prevented when tickets aren't reused? Best regards, Ben -- TLS 1.3 tutorial: https://bensmyth.com/publications/2019-TLS-tutorial/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (6145)
> Original Text > - > When a PSK is used and early data is allowed for that PSK > > Notes > - > I couldn't find restrictions that forbid early data for a PSK. Explaining > where such restrictions > could exist would be useful. E.g., PSKs might be associated with data that > forbids early data. > That's an oversight on my part: The sole extension currently defined for NewSessionTicket is "early_data", indicating that the ticket may be used to send 0-RTT data The client may only send early data when permitted: When a PSK is used and early data is allowed for that PSK, the client can send Application Data in its first flight of messages. Servers don't appear to be forbidden from consuming early data when keys don't permit them to. Perhaps I've missed that too. Or perhaps it doesn't matter: If a client does something they aren't supposed to, then they're only compromising their own security. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 8446 Early data, server response: deprotect vs. type checking
Section 4.2.10 requires a server receiving early data to behave in ways including (p53): * Ignore the extension and return a regular 1-RTT response. The server then skips past early data by attempting to deprotect received records using the handshake traffic key, discarding records which fail deprotection... * Request that the client send another ClientHello by responding with a HelloRetryRequest... The server then ignores early data by skipping all records with an external content type of "application_data"... What are the use cases for each behaviour? And why does the former rely on deprotecting, when checking record content types is surely more efficient? (I'm extending my TLS 1.3 tutorial -- https://bensmyth.com/publications/2019-TLS-tutorial/ -- to include discussion of early data and I'm struggling to understand the rationale behind these two behaviours.) Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
