Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

I think you convinced me. And to think of it, I never did like binary curves. :-) No binary curves for the future. :-) Tnx! Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Tony Arcieri Sent: Wednesday, July 15, 2015 22:32 To: Rene Struik Cc: tls@ietf.org

Re: [TLS] sect571r1

This I absolutely cannot agree. P521 must stay, as part of the supported NIST standard (which BTW we use). Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Brian Smith‎ Sent: Wednesday, July 15, 2015 19:40 To: Tony Arcieri‎ Cc: tls@ietf.org Subject: Re: [TLS]

Re: [TLS] sect571r1

I like Tony's recommendation - except that I'd rather not ‎lose the 571 curve. But I'm not going to fight the entire WG over this.  Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Tony Arcieri Sent: Wednesday, July 15, 2015 18:07 To: Dave Garrett‎ Cc:

Re: [TLS] DSA support in TLS 1.3.

patents expire. On 9/1/15 15:23 , Tony Arcieri wrote: On Tue, Sep 1, 2015 at 12:17 PM, Blumenthal, Uri -- 0553 -- MITLL <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote: I am not tracking patents - have neither time, nor interest in doing that. But I'm not releasing commercial

Re: [TLS] DSA support in TLS 1.3.

On 9/1/15 14:49 , Watson Ladd wrote: On Tue, Sep 1, 2015 at 2:02 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote: On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett" <tls-boun...@ietf.org on behalf of davemgarr...@gmail.com> wrote: On Tuesday, September 01, 20

Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

On 9/16/15, 4:19 , "TLS on behalf of Peter Gutmann" wrote: >Jeffrey Walton writes: >>Somewhat off-topic, why does TLS not produce a few profiles. One can be >>"Opportunistic TLS Profile" with a compatible security

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

For this reason (among others) I am against PureEdDSA. ‎HashEdDSA dooes the job well enough.  Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Nikos Mavrogiannopoulos Sent: Thursday, September 24, 2015 10:04 To: Ilari Liusvaara; Simon

Re: [TLS] Data volume limits

On 12/16/15, 10:50, "Watson Ladd" <watsonbl...@gmail.com> wrote: >On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL ><u...@ll.mit.edu> wrote: >> OK, let me try an extremely naïve approach. >> >> Say, an adversary observes a ton of

Re: [TLS] Data volume limits

OK, let me try an extremely naïve approach. Say, an adversary observes a ton of TLS traffic between A and B. Using approach that Watson and others outlined, he can now tell that this is not a truly random stream but a bunch of encrypted data. My question is, from practical real-world point of

Re: [TLS] Data volume limits

I like option (2) from Eric's taxonomy. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Eric Rescorla Sent: Tuesday, December 29, 2015 18:12 To: Dave Garrett Cc: Florian Weimer; tls@ietf.org Subject: Re: [TLS] Data volume limits On Tue, Dec 29, 2015 at 5:08

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

I think Watson made a good point about "omittable checks". ‎If an implementation A "omits" this mechanism, it should fail session establishment. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Alyssa Rowan Sent: Thursday, December 31, 2015

Re: [TLS] Data volume limits

KDF" with something newly-random isn't a bad idea at all. I don't think common crypto expertise would disagree. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Salz, Rich Sent: Monday, December 28, 2015 16:09 To: Blumenthal, Uri - 0

Re: [TLS] Data volume limits

Rescorla Sent: Monday, December 28, 2015 15:47 To: Blumenthal, Uri - 0553 - MITLL Cc: Florian Weimer; tls@ietf.org Subject: Re: [TLS] Data volume limits To be clear, the concern that we are trying to alleviate is encrypting too much plaintext with the same key (see the discussion by Watson

Re: [TLS] Data volume limits

Off-hand, key update or re-key without new/fresh‎ randomness sounds weird. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Eric Rescorla Sent: Monday, December 28, 2015 15:37 To: Florian Weimer Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits On Mon,

Re: [TLS] Consensus call for keys used in handshake and data messages

Key reuse often ends up causing problems. IMHO a more sound approach is (2). IMHO it isn't prohibitively expensive either. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Björn Tackmann Sent: Tuesday, June 14, 2016 05:23 To: tls@ietf.org

Re: [TLS] ECDH_anon

On 1/27/16, 12:47 , "Martin Thomson" <martin.thom...@gmail.com> wrote: >On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL ><u...@ll.mit.edu> wrote: >> Anon ‎!= Ephemeral, despite some similarities. > >From a protocol perspective, they ar

Re: [TLS] ECDH_anon

IMHO it's not a good idea to re-purpose existing cipher-suites and alter their observed behavior. Likewise for the name overloading.  Anon  ‎!= Ephemeral, despite some similarities.  My apologies if I'm missing the point or the frame of a larger issue. Sent from my BlackBerry 10 smartphone on 

Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

>>I’d state secp384r1 (...) as "NOT RECOMMENDED" to bother with, >> but still permitted > >I'd say it is a tad bit too strong of a wording for the strongest curve >supported by SChannel... +1 to Hubert. smime.p7s Description: S/MIME cryptographic signature

Re: [TLS] RSA-PSS in TLS 1.3

Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let alone available?  It may be worth asking the authors what's their opinion of FDH vs PSS in view of the state of the art *today*. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message  

Re: [TLS] SHA-3 in SignatureScheme

Speaking of PRF hash, I want to bring up the fact that‎ SHA-3 is a better PRF by design, as that was one of the explicitly stated competition requirements (unlike MD*, SHA-1, and SHA-2). Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From:

Re: [TLS] SHA-3 in SignatureScheme

On 9/2/16, 15:22 , "TLS on behalf of Eric Rescorla" wrote: But then we have: * AES and ChaCha (two modes for the former one even) * RSA and ECDSA * NIST curves and Bernstein curves * ECDHE key exchange an DHE key exchange only the SHA-2 stands

Re: [TLS] SHA-3 in SignatureScheme

+1 On 9/6/16, 7:47 , "TLS on behalf of Gilles Van Assche" wrote: Hello, For RSA PSS, I would suggest to consider: rsa_pss_shake128 rsa_pss_shake256 where SHAKE128 (or 256), as an exendable output function (XOF), directly

Re: [TLS] 32 byte randoms in TLS1.3 hello's

My guess is many TLS implementations don't have visibility into how the CSPRNG operates. That code does however, know which output values will be public and which not. For me, that implies that any good separation scheme applied within the TLS code that differentiates

Re: [TLS] possible new work item: not breaking TLS

I support allocating a time slot for the arguments against the draft-green (and similar/related approaches). I also support documenting the above arguments, possibly in a TLS WG draft. -- Regards, Uri Blumenthal On 7/13/17, 08:00, "TLS on behalf of Stephen Farrell"

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

TLS is a tool. Good guys want to use it to defend against the bad guys. Bad guys may want to use it against the good guys. (No surprise here, right?) You cannot “sabotage” the second use case without sabotaging the first one at the same time. Two decades ago Jeff Schiller said something that

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

+1 Current agenda does look backwards. IMHO, do as Stephen suggested. Regards, Uri Sent from my iPhone > On Jul 14, 2017, at 11:10, Stephen Farrell wrote: > > > Hiya, > >> On 14/07/17 15:51, Sean Turner wrote: >> Please let us know your thoughts. > > 80 minutes

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

A higher-level view on this issue. TLS has been designed as a protocol that allows two entities to communicate securely over a network controlled by an adversary, including abusive authorities. “But we (the (network) authorities) are the good guys, and we need to break the guarantees TLS

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

And why are you unable to understand that that in the case of an additional layer of attacker-generated crypto nestled within a TLS tunnel, as you posited, that the ability to simply detect the presence of such an additional layer of unexpected crypto, even without the ability to

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

> The standard definition of “traffic analysis” is deducing > information from the metadata and the patterns of communications. It > explicitly does NOT rely on knowing the content of the traffic (which > is assumed to be opaque). That's what I was trying to get across

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 7/17/2017, 12:45, "TLS on behalf of Roland Dobbins" wrote: On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote: > it could easily be enabled accidentally on the Internet, or coercively > required > of certain

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

But it's also important for understand that security is additive in nature, not all the criminals are bright or sophisticated, & so the emergence of a few smarter ones doesn't make those less so disappear. :-) It’s the Law Enforcement job to make the dumber ones disappear. The question

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 7/17/2017, 11:04, "Roland Dobbins" wrote: The actual concern of intranet operators is the inadvertent breakage of an important mechanism used for troubleshooting and security in the context of TLS-encrypted traffic on their own networks, within their own

Re: [TLS] chairs - please shutdown wiretapping discussion...

I’d rather not deal with this whole mess. -- Regards, Uri On 7/11/2017, 16:56, "TLS on behalf of Christian Huitema" wrote: On 7/11/2017 1:31 PM, Stephen Farrell wrote: > PS: There are also genuine performance reasons why the

Re: [TLS] chairs - please shutdown wiretapping discussion...

My $0.02: absolutely not on the Standards Track (for reasons already expressed by others), might be discussable if Informational. -- Regards, Uri Blumenthal On 7/10/17, 15:03, "TLS on behalf of Nico Williams" wrote: On Mon, Jul 10,

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

> ... the IESG could also decline to allow such a WG item to > get published. That’s what I’d expect and hope for. > Better skip the Q/A at the WG meeting -- it makes no difference as to > determining consensus, +1 > and no one needs the other side screaming bloody > murder and judging one

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

On Jul 14, 2017, at 15:51, Sean Turner wrote: > > And by the important business I was referring to the TLS and DTLS drafts. My apology. We’re in agreement then. ___ TLS mailing list TLS@ietf.org

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Except when it's the issue of mutual consent (rather than of a merely technical change). Otherwise - "we have to change one side" might turn into "have you pay me $50,000 every month, your opt-in isn't necessary". :-) Regards, Uri Sent from my iPhone > On Jul 14, 2017, at 12:45, Yoav Nir

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> Or are you simply trying to delay the inevitable? I'm open to any solution which meets the stated requirements & is deployable & usable on real-world production networks, without necessitating a total redesign of said networks & the complete social reorganization of the

Re: [TLS] datacenter TLS decryption as a three-party protocol

it's fine if it borrows from 1.0, as it isn't going to be the most secure setting anyway. Regards, Uri Sent from my iPhone > On Jul 23, 2017, at 03:02, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > >> On Thu, Jul 20, 2017 at 08:42:10PM +0000, Blumenthal, Uri - 0553

Re: [TLS] datacenter TLS decryption as a three-party protocol

;> >> I do not know what mechanism could do the latter, or off it even >> exists. But folding an RSA method in seems to do the job. I'd say >> it's fine if it borrows from 1.0, as it isn't going to be the most >> secure setting anyway. >> >> Regards, Uri >> &

Re: [TLS] datacenter TLS decryption as a three-party protocol

I think there's no way the connection can be established if the third party in control of the network does not allow that. My only goal here is to leave fewer possibilities to set the eavesdropping silently. Regards, Uri Sent from my iPhone > On Jul 23, 2017, at 10:33, Ted Lemon

Re: [TLS] datacenter TLS decryption as a three-party protocol

On Jul 23, 2017, at 15:37, Ted Lemon <mel...@fugue.com> wrote: > On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu > <mailto:u...@ll.mit.edu>> wrote: >> I think there's no way the connection can be established if the third party >

Re: [TLS] Consistency for Signature Algorithms?

> To clarify, you are arguing that P-384 should also be listed as MTI? no, I'm arguing either for dropping the curve from signature algorithms, or to bind RSA key sizes to hashes too    I don't think that either of these are good ideas. +1 Both of these ideas are pretty bad,

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> most of them already carry all that’s necessary (and more) to perform surveillance from inside the endpoint. Unfortunately, this is not the case. Quite the opposite, actually. It's already been explained why endpoint-based measures are impractical. If they were

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

You said you need to look at packets to see unauthorized access. How do you that access is unauthorized unless the authorization system is doing the monitoring? Over the years I've met with businesses who have these kinds of set ups. The way it usually works is that the analysis is

Re: [TLS] datacenter TLS decryption as a three-party protocol

> At the very least, a standards-track multi-party protocol like that can be > something that standards > like PCI, HIPAA and others can latch on to and say “Do TLS 1.3 without > backdoors unless you really > need to and in that case use *this*”. > That is better guidance than “Do TLS 1.3

Re: [TLS] datacenter TLS decryption as a three-party protocol

Maybe we are better off just retrofitting RSA-key-transport back into TLS-1.3? In that case at least the peer could refuse this method of key establishment, and one could safely assume that if a peer insists on that key establishment mechanism, this session will be surveilled? If I had to

Re: [TLS] datacenter TLS decryption as a three-party protocol

On 7/20/17, 16:32, "ilariliusva...@welho.com on behalf of Ilari Liusvaara" wrote: > Maybe we are better off just retrofitting RSA-key-transport back > into TLS-1.3? This has in fact been requested. Kenny Paterson said about the request:

Re: [TLS] datacenter TLS decryption as a three-party protocol

>>> This is exactly right.   We have a real problem here.   We should really >>> solve it.   >>> We should do the math.   :) >> >> Is there appetite to do this work? If we restrict this to two paths, one of >> which is >> spending years designing and implementing a new multi-party security >>

Re: [TLS] 32 byte randoms in TLS1.3 hello's

Respectfully disagree. Having two cryptographically independent PRNGs, one for public data and one for key material, IMHO is a good idea. Of course, both should be properly seeded - but that's a different issue. Regards, Uri Sent from my iPhone > On Jul 27, 2017, at 19:33, Dan Brown

Re: [TLS] Security review of TLS1.3 0-RTT

Chose not to provide replay protection?! I have to agree with Colm - it doesn't sound good. Care to justify? P.S. Care to name (another :) one security-related protocol that doesn't provide replay protection? Regards, Uri Sent from my iPhone > On May 3, 2017, at 21:42, Colm MacCárthaigh

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

It is a mathematical cryptographic term, and as such is incontrovertible. I say leave it in. Regards, Uri Sent from my iPhone > On May 18, 2017, at 16:58, Timothy Jackson wrote: > > One small nit. > >> ECDHE provides perfect forward secrecy > I thought we had

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

Daniel > >> On Thu, May 18, 2017 at 5:01 PM, Blumenthal, Uri - 0553 - MITLL >> <u...@ll.mit.edu> wrote: >> It is a mathematical cryptographic term, and as such is incontrovertible. >> >> I say leave it in. >> >> Regards, >> Uri >>

Re: [TLS] Idempotency and the application developer

On May 4, 2017, at 19:35, Watson Ladd wrote: > > Dear all, > > Applications have always had to deal with the occasional replay, > whether from an impatient user or a broken connection at exactly the > wrong time. But they've generally been rare, so human-in-the-loop >

Re: [TLS] draft-rhrd (Was: Re: Update on TLS 1.3 Middlebox Issues)

+1 to Stephen. Regards, Uri Sent from my iPhone > On Oct 8, 2017, at 18:34, Stephen Farrell wrote: > > > >> On 08/10/17 23:22, Eric Rescorla wrote: >> You seem to be responding to some other thread. > > Yep. I changed the subject line. > > Randy's substantive

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

> enforcing the default. The default being: > - Hash algorithm the same as specified in Signature Algorithm > - MGF1 hash is the same as above > - Salt length same as digest length above No problem with that being recommendation, but I've seen people claiming that

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

What Stephen is pointing at, is a server certificate (End Entity certificate) when using RSA-PSS public key id in the X.509 certificate can have RSA-PSS parameters in the public key id or can have them omitted. Yes. And I concur with him that it is better to omit them, enforcing

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

> . . . > This could get pretty messy: it requires a logic not used in any other > algorithm. I'd be more than happy to have an outright prohibition on EE PSS > key parameter restrictions in TLS 1.3 so implementers don't have to bother > with this. what about hardware

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Who cares about the objective? People are asking about the result. Regards, Uri Sent from my iPhone > On Oct 23, 2017, at 19:32, Ackermann, Michael wrote: > > NO > The objective is to be passively observe, out of band and not to be a MitM or > modify/inject text.

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

IMHO, get the TLS-1.3 standard out first, then start mucking with it. There's nothing yet to make "visibility" into. ;-) And in any case I'm against weakening the protocol, since there are other ways to accomplish the perlustrator's mission. Regards, Uri Sent from my iPhone > On Oct 22,

Re: [TLS] WGLC for draft-ietf-tls-tls13-vectors

If it's intended to be a "test-vector", then by all means it should be a standard. If it's just for illustration - Informational or BCP is fine. My $0.02. -- Regards, Uri Blumenthal On 5/8/18, 12:56, "TLS on behalf of Salz, Rich" wrote:

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

If those middleboxes already have sufficient alternative options, why do we spend time discussing this draft? Why do we need to add yet another alternative for them? Regards, Uri Sent from my iPhone > On Oct 19, 2017, at 13:08, Paul Turner wrote: > > > >> >>

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

+1 to Rich. -- Regards, Uri Blumenthal From: TLS on behalf of Rich Salz Date: Friday, October 20, 2017 at 09:59 To: Darin Pettis , "tls@ietf.org" Subject: Re: [TLS] Publication of

Re: [TLS] Preshared Keypairs for (D)TLS 1.2

MQV was not licensed as a part of the NSA ECC deal. If I has a choice, I’d pick HMQV or FHMQV – with understanding that there are likely to be licensing issues. And I think those protocols would rule out use of EC keys on most of the currently available hardware tokens. -- Regards, Uri

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

First they have to go through this vulnerability search dance with TLS-1.1 and achieve a reasonably complete move to TLS-1.2. Regards, Uri Sent from my iPhone > On Oct 22, 2017, at 16:49, Steve Fenter wrote: > > The main problem with not addressing the TLS

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

> On Jul 30, 2018, at 10:36, Dan Brown wrote: > > The TLS 1.3 draft sentence “They are no longer considered appropriate for > general use and should be assumed to be potentially unsafe” seems a bit > excessive. I suggest deleting it, and think that its encompassing paragraph > flows fine

Re: [TLS] integrity only ciphersuites

"Vulnerable-by-design ciphersuites"? Vulnerable to what? Suck sites are designed to provide end-point authentication and traffic integrity. Care to explain/show how these properties would not hold? Besides, it's been explained several times that some use cases do not require confidentiality,

Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

No they should not be recommended (as a typical TLS use case includes confidentiality requirement). Yes this WG should review them and make a security statement, e.g., like "we reviewed these suites and found that they do provide authentication and integrity protection. No other protection

Re: [TLS] integrity only ciphersuites

/cybersec/cybersec-bios/blumenthal-bio.html > On 21/08/18 13:10, Blumenthal, Uri - 0553 - MITLL wrote: >> "Vulnerable-by-design ciphersuites"? Vulnerable to what? > > Accidental use, at least. If libraries implemented this > it could create a need for "!NULL"

Re: [TLS] Doubts about a solution or new service/protocol

IMHO no it doesn't. TLS is just a way to provide secure pipes between the communicating entities. Making long-term signatures that persist after the connection is dropped had never been on the site of TLS. Regards, Uri Sent from my iPhone > On Jul 20, 2018, at 11:42, Walter Neto wrote: > >

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

> We've > generally decided to limit the number of algorithms we recommend (the > Recommended) column in the registry. I have trouble seeing any situation in > which we would have these curves as Recommended. And so "at hand" really > means (1) code points assigned and (2) some small number of

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

> This would result in an IANA registry with duplicated entries for brainpool > curves: the old, now prohibited code points and the new assigned ones. Is > this correct? No. The request could ask for the existing reserved codepoints to be re-used. No offense meant, but this does not

Re: [TLS] Proposals for draft-ietf-tls-subcerts-02

I object to re-interpreting/overloading the Critical flag. It has one and only one meaning: "If the parser does not understand the given attribute, it must abort parsing if this attribute is marked as Critical (or ignore this attribute and continue parsing if the Critical flag is not set)".

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

SHOULD NOT would probably be fine. MUST NOT is too strong, and probably needs revisiting. Regards, Uri Sent from my iPhone On Jul 19, 2018, at 06:32, Johannes Merkle wrote: >>> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3. >>> Those “you should not send these for

Re: [TLS] Broken browser behaviour with SCADA TLS

+1 to Rich and Peter. Regards, Uri Sent from my iPhone On Jul 9, 2018, at 08:20, Salz, Rich wrote: >> There Is No Such Thing As A Trusted Network > > That's a great aphorism, and we've all made lots of progress in working with > that assumption, but there are important cases where it is

Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]

Peter, I think your code did exactly right. The standard requires honoring KeyUsage.. Maybe if more implementations were diligent with this, the cert zoo we're observing would've been less wild... Regards, Uri Sent from my iPhone > On Nov 7, 2018, at 21:21, Peter Gutmann wrote: > > Viktor

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

Yes to what Viktor proposed. On 11/7/18, 11:27 PM, "TLS on behalf of Viktor Dukhovni" wrote: > On Nov 7, 2018, at 6:07 PM, Geoffrey Keating wrote: > > n general, though, what you're asking is "The CA signing this key has > instructed that I do not accept signatures made with

Re: [TLS] WG: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt

I'm with EKR on this. Regards, Uri Sent from my iPhone > On Sep 3, 2018, at 15:27, Eric Rescorla wrote: > > > >> On Mon, Sep 3, 2018 at 12:19 PM, Hubert Kario wrote: >> On Monday, 3 September 2018 17:30:15 CEST Eric Rescorla wrote: >> > On Mon, Sep 3, 2018 at 8:20 AM, Hubert Kario wrote:

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

Exactly. I for one am against such "enhancements" and agree that treating them as errors is the right way. Regards, Uri Sent from my iPhone > On Dec 1, 2018, at 20:44, Christian Huitema wrote: > > >> On 12/1/2018 11:14 AM, Tony Rutkowski wrote: >> >> The eTLS use case is an enterprise

Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?

A naive question: is HKDF implemented placing secret in the "salt" argument, and label in the "key" argument, as NIST 800-56B says? Or putting label into "salt" and secret into "key"? Regards, Uri Sent from my iPhone > On Mar 31, 2019, at 09:46, Ilari Liusvaara wrote: > >> On Sun, Mar 31,

Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

I agree with EKR. It's another type of PKI, in the sense that there's some infrastructure you have to trust, in addition to or instead of your own key pair. Some, myself included, would prefer facing the kinds of attacks that are possible with the traditional PKI, rather than those that IBC

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

On 5/31/2019, 17:34, "TLS on behalf of Geoff Keating" wrote: >> On 21 May 2019, at 2:08 pm, Hugo Krawczyk wrote: >> >> A clarification on the text suggest below by Russ. >> >> The way I see it, the external PSK as used in draft-ietf-tls-tls13-cert-with-extern-psk is not

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

I reviewed this draft (“browsed through” would be a more honest statement). I didn’t spot an obvious problem with it. One question that I have after reading it: I understand why one wants to implement this extension, but I don’t see how the two endpoints would arrive at that external PSK.

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

One question that I have after reading it: I understand why one wants to implement this extension, but I don’t see how the two endpoints would arrive at that external PSK. Sadly - we're back to the 1980's in terms of key management. The obvious answers are a) they meet to exchange keys, b)

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

On 5/6/19, 7:22 AM, "TLS on behalf of Hubert Kario" wrote: > Sure, and that was the really strange thing with TLS 1.2, why not just say > SHA-2 or better only, rather than adding mechanisms that were much, much > weaker than its predecessors? So the simple fix is just to use SHA-2

Re: [TLS] Re： Draft for SM cipher suites used in TLS1.3

AFAIK, all the ISO standards that IETF refers to, were defined elsewhere first, i.e., ISO defined them based on some open submissions, publications, etc. I fully agree with Rene – if you want the specs standardized, provide the complete specs, including the missing parts 1 and 3.

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

IMHO, placing the documents on GitHub would be perfect, and quite sufficient. Please make sure to post the name of the repo here. ;/) I leave it to others to decide whether they'd want copies of today PDF files sent to the mailing list directly. Regards, Uri Sent from my iPhone > On Aug 17,

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

ards Kepeng -- 发件人：李克鹏(易深) 发送时间：2019年8月19日(星期一) 17:38 收件人：sean+ietf ; joe ; caw 抄　送：tls@ietf.org ; "Blumenthal, Uri - 0553 - MITLL" ; Paul Yang 主　题：Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1..3 Hi WG chairs, Can we place th

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

One more thing: I would expect to use SIDH rather than SIKE. Because to emulate the security advantages of DH, you’d have to run two SIKE’s – one in each direction. From: TLS on behalf of "Panos Kampanakis (pkampana)" Date: Tuesday, July 30, 2019 at 3:37 PM To: "Scott Fluhrer

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

The nuisance with just a flag is the client can't express [what I think are] reasonable preferences. It should be able to say things like: Offhand, I don’t see at all why the client should be able to say any of these “don’t”s: * Don't do X25519 + P-256. This is just silly. * Don't do

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

I concur with Hubert, and think that DER in this context is perfectly OK. On 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario" wrote: On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :)

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

I support its adoption. From: TLS on behalf of Joseph Salowey Date: Thursday, February 13, 2020 at 12:13 PM To: "" Subject: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item. Please state

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

I agree with Watson's reasoning. We know now all we need to to start working on generic mechanisms. Regards, Uri Sent from my iPhone > On Feb 21, 2020, at 17:11, Watson Ladd > wrote: > > On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell > wrote: >> >> >> >>> On 21/02/2020 22:02, Watson

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

You may have a point regarding finishing this draft - but let's cross that bridge when we get there. :-) Regards, Uri Sent from my iPhone > On Feb 21, 2020, at 17:26, Stephen Farrell wrote: > >  > >> On 21/02/2020 22:11, Watson Ladd wrote: >> >>

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

I'm jumping in late - so apologies in advance for potential ignorant comments: On 2/12/20, 3:48 PM, "TLS on behalf of Martin Thomson" wrote: > Larger public keys and/or ciphertexts - if we need these, we're in serious > trouble. > To give you an idea, even at 1k, these will start being much

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

I don't expect you to be knowledgeable about 25+ proposed algorithms. I expect you to be knowledgeable about the ballpark of the new key sizes that practically all of the candidates use. The shortest keys are in the ballpark of a few KB, and I won't go into the size of the largest ones. You

Re: [TLS] TLS ECH, how much can the hint stick out?

IMHO, Rich is 100% correct here. If it’s not deployable (and to me it means **universally** deployable, not merely within the US), if fails *all* of the security goals completely. Regards, Uri > On Sep 11, 2020, at 09:27, Salz, Rich > wrote: > >  > I think we should be careful with the

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

I would prefer the minimum encoding length. From: TLS on behalf of "Salz, Rich" Date: Monday, October 5, 2020 at 22:23 To: Eric Rescorla , Marten Seemann Cc: "" Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints Can you just say “QUIC rules but use the minimum possible

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

I suggest that custom parameters should be allowed, and documented as completely under user/administrator responsibility. Ensuring that a custom modulus is not "too small" or "too large" (etc.) in that case is not your problem or your business. On 10/12/20, 13:32, "TLS on behalf of Ilari

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

In some cases toy key sizes are necessary. E.g., classes where your students break encryption because the keys are weak or small. Regards, Uri > On Oct 12, 2020, at 19:42, Peter Gutmann wrote: > > Ilari Liusvaara writes: > >> The Diffie-Hellman support in TLS 1.2 is severly broken. There

  1   2   >