Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one? Either way, I would support deprecating FFDHE completely. > On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni wrote: > > 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 in a naïve way. > > I am well aware that verifying the safety of the server's choice is > computationally taxing. > >> Now, as I mentioned in the WG meeting, it would be possible to detect >> if the server proposes a safe prime (it's not especially cheap, being >> several times as expensive as the rest of the DH operations, but it's >> possible), and that would prevent most of the problems that can happen > > I don't think it is realistic for the client to go to that much trouble. > The server's choice of parameters is signed by the server's public key. > What is the threat model here? Is the client trying to avoid servers > that shoot themselves in the foot by verifiably choosing bad parameters? > > The server could also have a strong DH group, but a terrible RNG with a > well known RSA private key: > >http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html > > If the server is not one of these or similar, and attests to its choice > of DH parameters, and they happen to be less than ideal, so be it. > Server operators should be encouraged to choose strong parameters, but I > see little reason for clients to second-guess that choice. > > If the DH parameter size is below a reasonable threshold (Logjam), a > client might balk, but otherwise I am not sure what practical problem > we're actually solving. > >> Of course, this works only if the legacy servers you are talking about >> actually do use safe primes... > > All the ones I know of use "openssl dhparam", which defaults to Sophie > Germain strong primes with generator 2. > > I strongly doubt there's a non-negligible server population with weak > locally generated groups. The only likely source of weak groups is > servers that used one the older now deemed weak groups published in > deprecated RFCs. > > So it might suffice to refuse specific known weak "standard" groups, > which would have a much lower impact than requiring particular standard > groups with no mechanism to negotiate these. > > -- >Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
On 7/30/21 5:31 PM, Sean Turner wrote: > >> On Jul 30, 2021, at 05:08, Hannes Tschofenig >> wrote: >> 4. Is the update to RFC 7525 relevant given that there is an update of RFC >> 7525 in progress (see >> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even >> near completion? > > I do not have a problem moving the text. I might also solve the can a > standard update a BCP question. > > What do people think? WFM (as co-author of 7525bis). FYI we plan to seek WGLC before IETF 112. Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni writes: >with confirmation from Peter Gutmann below that any custom groups we're >likely to encounter are almost certainly safe Well, I haven't examined every crypto library on the planet, it's not to say there isn't something somewhere that implements its keygen as: for i = 0 to 256 dhprime[ i ] = rand(); but of the ones I'm aware of, when you ask for DLP parameters you get something appropriate like Sophie Germain primes or FIPS 186 or equivalent, e.g. Lim-Lee parameter generation. >I don't see a realistic scenario in which sufficiently large ad-hoc server DH >parameters are a problem. +1. Also if mentioning specific published values it'd be good to go with 3526 rather than 7919 due to the non-use of 7919 in implementations (unless there are implementations using the 7919 primes while not implementing 7919 itself). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
Given that I got a response to a different message on this topic, and that Martin is making a similar point to that I made below, my guess is that this message got lost in the shuffle. On Sun, Jul 18, 2021 at 19:26 Michael StJohns wrote: > On 7/16/2021 7:55 PM, Christopher Wood wrote: > > This is the second working group last call for the "A Flags Extension > for TLS 1.3" draft, available here: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > Please review this document and send your comments to the list by July > 30, 2021. The GitHub repository for this draft is available here: > > > > https://github.com/tlswg/tls-flags > > > > Thanks, > > Chris, on behalf of the chairs > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > Hi - I have not followed the discussion of this document on the mailing > list so this review is only against the document itself. It's possible > that these concerns have already been discussed. > > > Section 2 requires (MUST) the generation of fatal illegal_parameter > alert upon reception of a mal-encoded extension (e.g. any trailing zero > bytes), but compare and contrast this with section 3 which is full of > MUST and MUST NOT declarations but with no concrete actions to be > taken. E.g. if I (server or client) send 0x01 0x10, and receive 0x01 > 0x11 from the client or server, wouldn't that be an illegal value as > I've added a bit not sent to me? Should that cause the same fatal > illegal_parameter alert? Alternately, "receiver MUST ignore received > bits that weren't sent" language could clean this up. > > Section 4 is a bit painful to read in that it took me three > read-throughs to understand that what the document is asking for is a > monolithic registry which requires "expert review" for all > registrations, but where the experts are responsible for the sub range > determinations. Usually, that's not the way the IANA works. If a > registry has distinct set of ranges, each range normally has a specific > registration procedure that the IANA follows before placing a parameter > in that registry. > > I'd strongly suggest reviewing RFC 8126 and chatting with the IANA to > see if its possible to reform the registration process along more normal > IANA lines. E.g.: > > 0-7 - Standards Action and Expert Request > 8-31 - Standards Action > 32 - 63 Specification Required or IETF Review (pick one) > 64-79 Private Use > 80-127 RFU or Expert Review > 128-2039 First Come First Served > > > > Absent these two points, the rest of the content looks good. I'd > recommend a draft pass to fix these two items. > > > Later, Mike > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
I think that this is largely good. I don't like how the IANA registry is structured and would like to discuss it more. I think that it is 0-31 (Standards Action), 32+ (Specification Required), but it doesn't say that. I think that the experimental range (64-79) should not be reserved. That's relatively valuable space that is being effectively burned forever. It is also highly dependent on judgment of experts, which gives those experts far more say in the use of the registry than is typical. (It also says that the registry is initially empty in S2, but it then defines a flag.) On Sat, Jul 17, 2021, at 09:55, Christopher Wood wrote: > This is the second working group last call for the "A Flags Extension > for TLS 1.3" draft, available here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > Please review this document and send your comments to the list by July > 30, 2021. The GitHub repository for this draft is available here: > > https://github.com/tlswg/tls-flags > > Thanks, > Chris, on behalf of the chairs > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
