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
> 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
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.
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
>
>
>>
> 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
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
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:
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 re
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
-
>> 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
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
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
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 me
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,
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?
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
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 tha
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
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
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 ci
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.
>
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
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
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
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 U
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
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
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
The client will reject the server's ServerHello in your example.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
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
>
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
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
>
> 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
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
> 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
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
37 matches
Mail list logo
