David Benjamin

@ericlaw Denotes a boolean in structured fields. #section-3.3.6" target="_blank" rel="nofollow noopener">rfc-editor.org/rfc/rfc8941.ht…

In Document Policy, what's the question mark before the 0 for?

@ericlaw Probably PSS and your decoder hasn't been updated for 1.3? The codepoints are no longer decomposed into hash/sig tuples as that's not how signature schemes work in general.

What is the server hoping for here?

TLS/1.3 changes the format of the CertificateRequest message??

@ericlaw TLS 1.2 changed a bunch of them too, to add the signature algorithm. Anything after ClientHello and bits of ServerHello has always been version-specific and fair game to change.

@h4kr @BruceDawson0xB That guidance always worried me. Asking devs to think about worst case bounds on every map feels akin to thinking about whether some missed check is exploitable. Much lower stakes, but still a bit error-prone of a default for my comfort.

@BruceDawson0xB I wondered about those containers before, and if they should have a DCHECK that n < $MEDIUM_SIZED_VALUE. But I'm not sure how you'd argue for a particular MEDIUM_SIZED_VALUE in a CL. :)

@taviso @GuidoVranken Different reuse there, but yeah X509's setters basically don't work. Except you need to setters to issue certs, so it's a mess. No idea whether anyone actually relies on this particular case. I just reviewed the diff and noticed it broke something they previously had code for.

@GuidoVranken I was so annoyed when I found this lol marc.info/?l=openssl-use…

@BRIAN_____ It also catched bugs. We learned as a result that a few projects imported RSA keys wrong and swapped p and q! They just never noticed because CRT would always fail and then fallback in OpenSSL, making RSA signing unnecessarily slow.

@DrawsMiguel @shafikyaghmour I want a strict aliasing sanitizer, less to check my code (though that too) but really to demonstrate that no real world C code actually follows that rule.

@BRIAN_____ @djco @FiloSottile The spec reference in the bug is wrong; ClientHello.legacy_version is not the same as the record layer version. And yeah I doubt that is the issue. The record layer version is totally meaningless and vestigial.

@djco @FiloSottile @davidben__ I wonder if the issue is really that. I suspect the reporter is speculating. I wouldn’t be surprised if the real reason is cipher suite incompatibility, e.g. server requires non-ECDHE RSA key exchange. Presumably the peer is Schannel which does version negotiation pretty OK.

@FiloSottile @davidben__ any thoughts on github.com/rustls/rustls/…? (What version to send in ClientHello?)

@hanno @buherator @agl__ Thanks to that mess, it takes more bytes to encode RSA-PSS *parameters* in X.509 than to encode an entire ECDSA signature. PSS is singlehandedly the reason X.509 signature algorithms aren't a plain enum.

@buherator @agl__ RSA-PSS allows you to choose a hash function, a mask generation function (for which there is only one option), a salt length and a hash function for the mask generation function (yes, you can have a pss sig with two different hash functions). any more questions?

Picking parameters: imperialviolet.org/2022/03/15/pic…. (It was too long for Twitter.)

@FiloSottile @taviso @GuidoVranken Whether it's a bug in ModSqrt is up to interpretation. Tonelli-Shanks ultimately only works for primes. Always terminating is prudent. But accepting random attacker-supplied coefficients is a bad idea and forbidden by RFC5480. IMO that's the root bug, which doesn't affect Go.

@taviso @GuidoVranken @davidben__ Yeah, we have the same issue at the bignum layer, but we don't support custom curves, so we don't know of any vector of attack. In fact, I am working to make all of math/big unreachable from crypto packages. Yay for limiting complexity and attack surface :D

This was a fun one to work on, @davidben__ helped track it down to a bug in the Tonelli-Shanks implementation in OpenSSL.

@bascule @SchmiegSophie @cryptodavidw @cronokirby Malleability of (r, s) aside, parsing ECDSA signatures with DER should be perfectly compatible with real world TLS. Our implementation is strict, and OpenSSL hasn't accepted invalid DER here since 2015.

@SchmiegSophie @cryptodavidw @cronokirby Yeah, needs low-s normalization to be nonmalleable

mesur-io.github.io/post-quantum-s… Maybe a bit of a hot take, but I feel like you should just encode public and private keys as a string of bytes, and treat them as completely opaque blobs. Not sure what you really gain by exposing the internal structure as JSON

@ericlaw @sleevi_ It is usually what I do. The formats are... just barely boring enough to for it to be bearable. I meant to write a tool, but I really wanted it be reversible (like der-ascii). Working out a design I liked took more time than I had available.

I would ask @sleevi_ or @davidben__ but I expect they just read the raw hex directly.

Is there a site where I can paste a hexdump of a TLS ClientHello or ServerHello and get a parsed view back?

@RichSalz @sleevi_ @bascule @cwallace_bass I still don't even know how to read the new syntax! I can guess at it, but I've yet to have to learn it properly.

Another ASN.1 question which eludes me: When should a Context-Specific field have the constructed bit set-or-not-set? RFC5958's OneAsymmetricKey sets it for a context-specific BIT STRING (publicKey) RFC2459 appears NOT to set it for GeneralName alts? cc @sleevi_ @RichSalz

@sleevi_ @bascule For DER, the type alone determines constructedness, so you can kinda pretend it's part of the tag, even if it technically isn't. BER has this awful constructed strings encoding, so some types might be either in BER.

@sleevi_ @bascule Put another way: constructed is a property of the value, not the tag. It tells you whether the value is more TLVs or some random leaf element. So EXPLICIT is always constructed (wraps another TLV). IMPLICIT replaces the tag, so its constructed bit is based on the inner element.

I look forward to all the latent X.509 bugs around 2050, as we rollover from UTCTime to GeneralizedTime. Did you think we were done with two-digit years after Y2K? Well, X.509 has some news for you!

@__phantomderp @strega_nil @DrawsMiguel imperialviolet.org/2016/06/26/non… is the memcpy language bug. That one is bad enough that we had to add wrapper functions for memcpy because constantly worrying about whether a slice could be empty is not reasonable.

@__phantomderp @strega_nil @DrawsMiguel Fixing NULL + 0 would also be good. Both it and the memcpy(NULL, 0) language bug affected real world code in BoringSSL. If you have a function that takes ptr,len, NULL,0 is the natural way to say empty slice. But C is full of unnecessary places that break when you do that.

@RichSalz Well, AES is still significant progress. For GHASH, BearSSL has a writeup of a very neat strategy. I have some code I can contribute there if interested.