Re: [TLS] PR#345: IANA Considerations
I think the TLS 1.3 IANA considerations should just deal with setting up the recommended column and marking it for the cipher suites/extensions that are described in the 1.3 document. Other cipher suites/extensions can be marked as recommended through other documents. On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" wrote: >On Nov 17, 2015, at 16:40, Eric Rescorla wrote: >> >> > 1. The Cipher Suites "Recommended" column was populated based on >> > the Standards Track RFCs listed in the document (and I removed the >> > others). >> >> Isn’t it just the MTI suites listed in s8.1? >> >> Maybe I need to go check the minutes, but I thought it was the >> Standards Track ones, not the MTI ones that we agreed on. >> The difference here is largely the FFDHE cipher suites and CCM. > >From Jim’s notes in the etherpad: > >AOB >SPT: Requests for additional ciphers from others. Listing in A.4 > Suggest thinning it down to the SHOULD/MUST list only. >EKR: Need to encourage support for PSK variants >EKR: Looking at the difference between the "good" list and the "safe" list and >the "no opinion" list >EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is good. > >spt >___ >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
[TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448
Whoops, thanks for the correction. It should be the code point assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448, Ed25519 and Ed448. Thanks, Joe On 1/12/16, 6:24 AM, "Simon Josefsson" wrote: >Adam Langley writes: > >> Curve25519, as the name suggests, operates on 255-bit numbers. When >> encoded as bytes, there's obviously a 256th bit that needs to be >> specified. >> >> Curve25519 implementations didn't set the bit but did used to vary on >> how they parsed it. Some would take a 256-bit number and reduce it >> while others would ignore the bit completely. >> >> However, I believe that implementations have converged on ignoring it. >> That behaviour is specified in draft-irtf-cfrg-curves and tested via >> the test vectors. >> >> Currently >> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 >> says that implementations SHOULD reject inputs with the high-bit set. >> I think that should be dropped. The X25519 function is specified in >> terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec >> should just use that draft. > >I agree. > >/Simon ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
