Sorry, sent from the wrong address.
On Tue, Jan 19, 2016 at 5:19 PM David Benjamin <david...@google.com> wrote:
> On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck <ha...@hboeck.de> wrote:
>
>> Hi,
>>
>> I generally like the idea of simplifying the different algorithm
>> negotiation things, but:
>>
>> On Fri, 15 Jan 2016 20:45:34 +0000
>> David Benjamin <david...@chromium.org> wrote:
>>
>> > [2]
>> > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
>> > this is wire-compatible with TLS 1.2.
>> > - 0x0101 - rsa_pkcs1_md5
>> > - 0x0201 - rsa_pkcs1_sha1
>> > - 0x0301 - rsa_pkcs1_sha224
>> > - 0x0401 - rsa_pkcs1_sha256
>> > - 0x0501 - rsa_pkcs1_sha334
>> > - 0x0601 - rsa_pkcs1_sha512
>> > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
>> > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility
>> > but ignored in TLS 1.3.
>>
>> I think a couple of them (esp. everything with dsa and _md5) should get
>> a diediedie rfc and never be seen again.
>>
>
> Sounds good. I included all the TLS 1.2 values thinking we'd want to
> retroactively express TLS 1.2 (DSA, MD5, and SHA-1 warts and all) this way
> too. But leaving it alone is probably simpler. Reserving the range should
> be sufficient to keep collisions out.
>
> If TLS 1.3 takes this proposal, I expect that I will make BoringSSL
> implement TLS 1.2 this way (with whatever quirks are needed around ECDSA)
> for convenience, but there's no reason this needs to be reflected in the
> spec.
>
>
>> > - rsapss_sha256
>> > - rsapss_sha384
>> > - rsapss_sha512
>> > - ecdsa_p256_sha256
>> > - ecdsa_p256_sha384
>> > - ecdsa_p256_sha512
>> > - ecdsa_p384_sha256
>> > - ecdsa_p384_sha384
>> > - ecdsa_p384_sha512
>> > - ecdsa_p521_sha256
>> > - ecdsa_p521_sha384
>> > - ecdsa_p521_sha512
>> > - eddsa_ed25519
>> > - eddsa_ed448
>>
>> Do we really need that many?
>> I think the "complexity zoo" of TLS is one of its current downsides and
>> I really think we should go with fewer options in the future. Can we
>> strip that down to - below 5 or something? (personal opinion: Strip
>> down to 2, but this may be too radical for now.)
>>
>
> Brian Smith proposed elsewhere in the thread to cutting the ECDSA ones
> down to just
> - ecdsa_p256_sha256
> - ecdsa_p384_sha384
> - ecdsa_p521_sha512
> and folding them into the TLS 1.2 compatibility ECDSA values, which I
> think I am in favor of. I'm personally okay losing P-521 too since
> BoringSSL doesn't advertise it, but I imagine others might object, so
> *shrug*.
>
> That brings us down to 8. No strong opinions from me on whether we need
> all three rsapss_* values. I just took what was in the 1.3 draft.
>
>
> David
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
