Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

I'm having a bit of a hard time following email quotes containing diffs of diffs, so I may be misinterpreting who is arguing for what, but I think I agree with Daniel? I'm not sure. :-) I think: - We can't usefully change the interpretation of ClientHellos without the sigalgs extension. In

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

Given the few responses received thus far, we're going to extend this WGLC for another two weeks. It will now conclude on August 13, alongside the WGLC for draft-ietf-tls-cross-sni-resumption. Best, Chris, for the chairs On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote: > This is the

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Given the few responses received thus far, we're going to extend this WGLC for another two weeks. It will now conclude on August 13. Best, Chris, for the chairs On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote: > This is the working group last call for the "Transport Layer Security >

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Sat, Jul 31, 2021, at 06:25, Carrick Bartle wrote: > are you opposed to fully deprecating FFDHE? If so, why? No so much opposed as that it is not necessary. Though the TLS 1.2 variant is - as others have noted - close to impossible to negotiate the "good" groups, it's not concretely bad

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

Daniel, So the current proposal is that signature_algorithms is always included. I understand that with that in mind it might make sense to also remove the other text as well. What do others think? spt > On Jul 30, 2021, at 12:25, Daniel Migault wrote: > > Hi, > > Just to sum, up my

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

> On Jul 30, 2021, at 05:08, Hannes Tschofenig > wrote: > > I have no problem with the suggestion. > > A few other observations: > > 1. FWIW: The reference to [Wang] is incomplete. The same ref was used in RFC 6194, but we could also use:

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Hi Martin, Actually, a clarification question (more relevant to the other thread : are you opposed to fully deprecating FFDHE? If so, why? > On Jul 29, 2021,

Re: [TLS] Point Compression

I propose a method to compress NIST curves as defined in https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html Its main benefit is that the compressed point fits into field size / group order size. There is no additional byte needed. This encoding is enabled by by modifying key generation.

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

On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote: > > Was it wrong to generate server-side DH parameters? > > The problem is that it is hard for the client to distinguish between a > well designed server vs a server that isn't as well written, and > selects the DH group

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

> Was it wrong to generate server-side DH parameters? The problem is that it is hard for the client to distinguish between a well designed server vs a server that isn't as well written, and selects the DH group in a naïve way. For example, if the server just selects a random prime and a random

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

On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote: > >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code > >points that use negotiated groups from the group list. But it is far from > >clear that this is worth doing given that we now have ECDHE, X25519 and

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Sorry, the title will be changed in the next version, which I'll be posting as soon as possible. You are correct about the scope of the work. > On Jul 29, 2021, at 5:41 PM, Martin Thomson wrote: > > I support the *contents* of this document. The title, however, I can't agree > to. So I

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

[TLS] Point Compression

As requested during ekr's presentation , I will volunteer to write up a draft for defining new "supported groups" for compressed NIST curves. I didn't see/hear any objections during the tls-wg meeting, but thought I should probably confirm on the list before I

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

Hi, Just to sum, up my initial comment proposed to mention as being removed remove the texts mentioned below. Since Sean mentioned that removing a text with MUST can be problematic, for the first text we can also just explain that in the context of this draft, the first text ends in being some

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

I have no problem with the suggestion. A few other observations: 1. FWIW: The reference to [Wang] is incomplete. 2. The references to the other papers use the websites of the authors or project websites. I would use more stable references. 3. Kathleen's affiliation is also outdated. 4. Is