Re: [TLS] Adoption call for draft-rescorla-tls-rfc8446-bis

I support adoption and am willing to help review. In case anyone else finds it helpful, here's a diff from RFC 8446: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=rfc8446&url2=draft-rescorla-tls-rfc8446-bis-00 David On Wed, Sep 2, 2020 at 10:02 AM Ben Smyth wrote: > I support adoption

Re: [TLS] TLS WG GitHub interaction

+1, issue discussion mode with email summaries sounds like the best option On Wed, Oct 21, 2020 at 4:08 PM Eric Rescorla wrote: > > > On Wed, Oct 21, 2020 at 3:51 PM Christopher Wood > wrote: > >> RFC 8874 describes several different methods for using GitHub, ranging >> from the lightweight "do

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

I support adoption of draft-vvv-tls-cross-sni-resumption. David On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich wrote: > > >- Hmmm... I think it probably goes in this draft, but I'm open to >being wrong. > > > > That’s okay with me. > ___ > TLS mail

Re: [TLS] Adoption call for "Secure Negotiation of Incompatible Protocols in TLS"

I support adoption. David On Thu, Jul 29, 2021 at 5:33 PM Martin Thomson wrote: > On Fri, Jul 30, 2021, at 04:20, Christopher Wood wrote: > > Based on positive feedback during this week's meeting, we'd like to > > start an adoption call for "Secure Negotiation of Incompatible > > Protocols in TL

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

I support adoption. David On Mon, Aug 9, 2021 at 11:24 AM Loganaden Velvindron wrote: > I also support adoption. > > On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle > wrote: > > > > I support adoption. > > > > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > > > This is a working group c

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

I support adoption. David On Tue, Mar 28, 2023 at 3:41 PM Martin Thomson wrote: > Adopt. But please include an example, even if the public key is > 0x010203040506... > > On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote: > > At TLS@IETF116, the sense of the room was that there was WG support to

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

I support adoption. David On Wed, Dec 6, 2023 at 4:16 PM Rob Sayre wrote: > Hi, > > I support adoption. > > thanks, > Rob > > > On Tue, Dec 5, 2023 at 9:35 PM Deirdre Connolly > wrote: > >> At the TLS meeting at IETF 118 there was significant support for the >> draft 'TLS 1.2 is in Feature Free

Re: [TLS] Proposal: a TLS formal analysis triage panel

Hi Deirdre, Thanks for this, I think this is a great plan. From the perspective of standards work, more formal analysis is always better, and this seems like a great way to motivate such work. That said, it's unclear to me whether this review would be a hard requirement to pass WGLC. Let's say a

[TLS] close_notify and TLS 1.3

Hello all, Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 did. I believe that has issues and this might be the right time to fix them. The purpose of close_notify is to protect against data truncation attacks, each side is required to send close_notify before closing the wri

Re: [TLS] close_notify and TLS 1.3

be > something that harks back to SSL3 or even earlier. We aren't going to > make it so that you can rely on this behaviour, but we might be able > to make it possible to half-close, which for new protocols using TLS > could be hugely useful. > > On Sat, Nov 11, 2017 at 5:

Re: [TLS] close_notify and TLS 1.3

I've sent out a PR: https://github.com/tlswg/tls13-spec/pull/1092 <https://github.com/tlswg/tls13-spec/pull/1092> It might be a little verbose but I think it explains and solves the problem. Please let me know what you think! Thanks, David Schinazi > On Nov 12, 2017, at 09:47,

Re: [TLS] TLS 1.3, how to close the read side of a connection?

en truncated, and in this example it does get truncated. Thanks, David Schinazi > On Mar 7, 2018, at 09:51, Eric Rescorla wrote: > > Well, this is like TCP in that respect. You send close_notify and then you > either stop reading off of or close the TCP socket. > > -Ekr > &

Re: [TLS] TLS 1.3, how to close the read side of a connection?

ation-layer. > > For client read side in above case, it means that the server side MUST > deliver a close_notify. But it does not say if a client initiates the TLS > closure, how could the client indicates the server for a close_notify alert. > > Thanks for the suggestion of TC

Re: [TLS] TLS 1.3, how to close the read side of a connection?

LS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan > Sent: 07 March 2018 20:54 > To: David Schinazi > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection? > > Hi David, > > The case I can think of now is the START TLS protoco

Re: [TLS] please welcome new co-chair Chris Wood

Congratulations, Chris! David > On Jul 12, 2018, at 06:15, Benjamin Kaduk wrote: > > Hi everyone, > > Please welcome Chris Wood as a third TLS co-chair, joining > Sean and Joe at the helm. Chris will be in Montreal, so be > sure to introduce yourself! > > Thanks, > > Ben > > __

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

I support adoption, and I'm happy to review it. David > On Jul 24, 2018, at 19:16, Joseph Salowey wrote: > > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ >

[TLS] Are we holding TLS wrong?

Hi everyone, Over in the Babel working group we have a draft about securing Babel with DTLS: https://tools.ietf.org/html/draft-ietf-babel-dtls-01 It's 5 pages long, could any TLS experts please give it a quick read and let us know if we're using DTLS correctly? Also, should the document contain

Re: [TLS] Are we holding TLS wrong?

to > what we have done with DTLS-SRTP. This would also allow you to cover the > multicast security case. > > Ciao > Hannes > > *Gesendet:* Donnerstag, 08. November 2018 um 11:30 Uhr > *Von:* "Fossati, Thomas (Nokia - GB/Cambridge)" > *An:* "David Schinazi&qu

Re: [TLS] Are we holding TLS wrong?

Thanks for the feedback Thomas! Responses inline. On Wed, Nov 7, 2018 at 8:30 PM Fossati, Thomas (Nokia - GB/Cambridge) < thomas.foss...@nokia.com> wrote: > One high level thing which I can't extrapolate from the draft (which is > probably due to my ignorance with Babel) is whether you envisage t

Re: [TLS] Are we holding TLS wrong?

f the node > crashing and dumping state. The same applies during a rollover of the > 32-bit counter. Of course, that might not be permitted by the threat > model. > On Thu, Nov 8, 2018 at 9:15 AM David Schinazi > wrote: > > > > Hi everyone, > > > > Over in

Re: [TLS] Are we holding TLS wrong?

Hi everyone, Thanks again for your feedback, we've updated the document to reflect it: https://tools.ietf.org/html/draft-ietf-babel-dtls-02 https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-02 David On Tue, Nov 13, 2018 at 1:41 PM Juliusz Chroboczek wrote: > > - s2.5 Not sure what th

[TLS] Concerns with draft-kinnear-tls-client-net-address

Hi Tommy, thanks for the presentation. I do not think the draft succeeds at addressing its goals. The mechanism is a fine way for the client to receive its public address (assuming the server is honest) but I can't see anything useful the client can do with that information. 1) Keepalives The

Re: [TLS] comment on draft-kinnear-tls-client-net-address

Hi Hubert, Can you elaborate on how "TLS is a providing integrity and authenticity to the IP address information"? In my understanding, TLS only provides integrity and authenticity to a byte stream, not to how your byte stream is being transported over the network. Thanks, David On Mon, Mar 25,

Re: [TLS] comment on draft-kinnear-tls-client-net-address

Ah, I see - thanks. In other words, the proposal requires trusting the server and the reply comes before the identity of the server has been authenticated. David On Mon, Mar 25, 2019 at 4:54 PM Hubert Kario wrote: > On Monday, 25 March 2019 15:09:21 CET David Schinazi wrote: > >

[TLS] Requesting WGLC for draft-ietf-tls-ticketrequests

Hi folks, We've submitted draft-ietf-tls-ticketrequests-01 (diff ). We believe this version addresses the comments we've received so far, and the authors feel this doc

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi folks, I've chatted with Daniel and Chris offline, and I think there might have been some miscommunication here. Please allow me to rephrase what I think is going on, and please let me know if this accurately represents your views. Daniel has a IoT use-case where due to memory constraints, a c

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Thanks. I've updated the PR to take MT's suggestion s/SHOULD/will/. David On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson wrote: > On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: > > resources. Therefore, the number of NewSessionTicket messages sent > > SHO

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

this sentence > should be struck, or rewritten in non-2119 English. If the editors wish to > keep the text, I think there should be a comma after "send". > > These proposed edits make sense to me, because servers can't know if their > tickets will be used successfully (

Re: [TLS] progressing draft-ietf-tls-ticket-request

Hi Viktor, I like the editorial changes in your PR #18, as they do a good job of explaining things. However, I don't think we should add a second count in this extension. Allowing ticket reuse is not something we have consensus for in the WG, and I would like to see this discussion happen in the T

Re: [TLS] progressing draft-ietf-tls-ticket-request

On Sat, Feb 29, 2020 at 2:57 PM Nico Williams wrote: > On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote: > > However, I don't think we should add a second count in this extension. > > Allowing ticket reuse is not something we have

Re: [TLS] progressing draft-ietf-tls-ticket-request

On Sat, Feb 29, 2020 at 2:28 PM Viktor Dukhovni wrote: > But the second count is not just or even primarily for reuse, it is also > useful for the non-reuse case as explained in the new text. The fact > that it then possible to cleanly express reuse is a byproduct, and I > also don't mean to enc

Re: [TLS] progressing draft-ietf-tls-ticket-request

; On Sat, Feb 29, 2020 at 04:34:17PM -0800, David Schinazi wrote: > > > I think that what you bring up here has value, but I do not see it in > > scope of draft-ietf-tls-ticket-request. > > I don't see how it can be out of scope. The abstract clearly > puts it in sco

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

No. David On Wed, Mar 4, 2020 at 10:49 AM Christopher Wood wrote: > On 4 Mar 2020, at 8:06, Sean Turner wrote: > > > one more time ... > > > > All, > > > > The purpose of this message is to help the chairs judge consensus on > > the way forward for draft-ietf-tls-ticketrequests. The issue at ha

Re: [TLS] Proposed change in TLS-Flags

Hi Yoav, Could you elaborate on the rationale for this change please? I was assuming that the ability for servers to send extensions not requested by clients was useful. Thanks, David On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir wrote: > Hi > > I’ve just submitted the following PR: > > https://git

Re: [TLS] Proposed change in TLS-Flags

too onerous to require that > > the client indicate support first. > > > > Yoav > > > > > On 1 Jul 2020, at 2:30, David Schinazi > wrote: > > > > > > Hi Yoav, > > > > > > Could you elaborate on the rationale for this change ple

Re: [TLS] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

Thanks for the update! I've reviewed -04 and I think the draft is ready to move forward. Regards, David Schinazi > On Mar 28, 2017, at 15:43, Daniel Migault wrote: > > Hi, > > Thank you Jim for the update. Here is the version resulting from the > discussion we ha

Re: [TLS] Adoption call for TLS Flag - Request mTLS

I support adoption. David On Tue, Apr 2, 2024 at 12:22 PM Sean Turner wrote: > At the IETF 119 TLS session there was some interest in the mTLS Flag I-D ( > https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see > previous list discussions at [0]. This message is to judge consen