Re: [TLS] sect571r1

Hey, Except if someone has a real need for it, I would favour removing p571 and keep secp521r1 as the maximum … Cheers, B. > On 15 Jul 2015, at 20:13, Dave Garrett wrote: > > In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the > ones actually used. (per Sean's recomm

Re: [TLS] 4492 ECDH_anon

>> I have never understood why 4492 doesn't claim forward secrecy for >> ECDH_anon suites. Can someone explain why this doesn't have an 'E’? > > I wasn’t there for the original 4492, but I think it’s because the old > anonymous ciphersuites were called DH_anon (no E). > > They both provide fo

Re: [TLS] ban more old crap

> On 25/07/15 06:46, Viktor Dukhovni wrote: >> I hope, that by ~2017, RC4 will no longer be required either, and >> we'll be able to disable RC4 in Postfix at that time. > > Seems to me that should be a reasonable match for expecting to see > TLS1.3 getting deployed in lots of parts of the mail i

Re: [TLS] Our fearless leader

Wow, he brings the word fearless to another level =P > On 28 Jul 2015, at 01:11, Salz, Rich wrote: > > Sean, at the CFRG meeting last week, wasn't bothered at all when all the > seats were taken. ___ TLS mailing list TLS@ietf.org https://www.ietf.or

Re: [TLS] Data volume limits

> On 15 Dec 2015, at 22:17, Watson Ladd wrote: > > I don't think that's what I intended: I think the limit should be > ciphersuite specific. Unfortunately that requires more work. > > On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote: >> >>> I wanted to get people's opinions on whether tha

Re: [TLS] RSA-PSS in TLS 1.3

> PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related > vuln that could've been prevented by using RSA-PSS was found 2 months > ago [1]. The last one in a major implementation (BERserk) was in 2014. > > tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable. > Let'

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

I support adoption of this work. B. > On Sep 2, 2020, at 6:18 PM, Christopher Wood wrote: > > This email begins the adoption call for draft-rescorla-tls-rfc8446-bis. As > mentioned [1], this updates language and fixes some errata against RFC8446 > (as identified below). No other semantic chan

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

I support adoption. B. > On Jul 29, 2021, at 10:22 PM, 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 TLS." The > document may be found here: > > https://datatrack

Re: [TLS] RFC 8446 on The Transport Layer Security (TLS) Protocol Version 1.3

Congratulations everyone !! :) B. > On Aug 10, 2018, at 4:56 PM, Benjamin Kaduk wrote: > > A big congratulations and thanks to Ekr, the chairs, Kathleen, and all the > researchers and contributors who helped make this happen! > I'm looking forward to seeing the deployment share grow as we get th

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

I support adoption > On Aug 17, 2018, at 10:32 AM, Sean Turner wrote: > > At the TLS@IETF102 session, there seemed to be some interest in adopting > draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to > determine whether there is WG consensus to adopt this draft as a WG ite

Re: [TLS] ETSI releases standards for enterprise security and data centre management

> The WG is chartered to make TLS a fast, secure, confidential transport > layer. Let's keep the charter goals in mind. > >--dkg + 1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Binder key labels for imported PSKs

Hi Chris, I expect that the idea is to have key separation for the binder key depending on the usage. Having this kind of property is always a good practice, so I agree with Jonathan on this. B. > On Sep 3, 2019, at 1:29 AM, Christopher Wood wrote: > > Hi folks, > > > Per Jonathan Hoylan

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

I support adoption. B. > On Nov 21, 2019, at 6:53 AM, Salz, Rich wrote: > >  >> >> I think it's a good starting point. I support adoption. > > Strongly agree. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Re-chartering TLS

LGTM, I agree with using “resource" instead of “size”… My understanding is that “security” is broad enough to cover new authentication mechanisms and that “privacy" will be broad enough to cover “metadata protection” if needed, correct? B. > On Jan 17, 2020, at 4:31 AM, Christopher Wood wrote:

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Hi all ! > On 16 Mar 2016, at 19:49, Colm MacCárthaigh wrote: > > On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny > wrote: > Much better would be implementing an optional padding feature for the AEAD > modes. Something like this draft proposes: > > https://to

Re: [TLS] Separate APIs for 0-RTT

Please forgive me for this naive question, but is there a specific incentive for using “SHOULD” instead of “MUST" only enable 0-RTT application data upon explicit opt-in by the application... My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the f