[TLS] Early code point assignments for 25519/448 curves
All, We’ve received an early code point assignment for the following 4 (four) elliptic curve points that will go in the "Supported Groups" Registry: // ECDH functions. ecdh_x25519 ecdh_x448 // Signature curves. eddsa_ed25519 eddsa_ed448 These points will be included in the following 2 (two) drafts: draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. Early code points are permitted in the “Supported Groups” registry and the chairs (that’s us) need to determine whether there is support for these assignments. Some input has already been received and those people do not need to respond again to this call, but we’d like to hear from others whether they support early code point assignment for these curves. If you do not please state why. We’re looking for input by November 30th. J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Issue #348: 32bit timestamp in ServerConfiguration
>From the issue: <<< As far as I can see, the only timestamp used is expiration_date in the ServerConfiguration (apart from X.509 validity checks which require synchronised clocks). This is defined as seconds since UNIX epoch, and will overflow sooner than later. Maybe either use a relative amount of seconds here, or expand to a 64bit value!? I suggest to use 32bit network byte order (same as ticket_lifetime_hint), which value are the seconds how long this configuration is valid, and thus may be cached for at most this amount of seconds. >>> I don't want to see this change to a relative time. That will mess with our ability to create ServerConfiguration objects that live outside of the handshake. I have no real objection to expanding this to 64bit though. (I'm personally OK with stating that this is modulo 2^32, but recognize how that might result in problems.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
Thanks Sean, I support early code point assignment for these curves. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner Sent: Monday, November 23, 2015 6:21 AM To: Subject: [TLS] Early code point assignments for 25519/448 curves All, We’ve received an early code point assignment for the following 4 (four) elliptic curve points that will go in the "Supported Groups" Registry: // ECDH functions. ecdh_x25519 ecdh_x448 // Signature curves. eddsa_ed25519 eddsa_ed448 These points will be included in the following 2 (two) drafts: draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. Early code points are permitted in the “Supported Groups” registry and the chairs (that’s us) need to determine whether there is support for these assignments. Some input has already been received and those people do not need to respond again to this call, but we’d like to hear from others whether they support early code point assignment for these curves. If you do not please state why. We’re looking for input by November 30th. J&S ___ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls%0a&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c261c2c7f387a43402fae08d2f41163f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=u5jdsbd0xLIjVOBsxqiaed3hzP5c1JCenrcGW6LVUVE%3d ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration
On Mon, Nov 23, 2015 at 10:28:41AM -0800, Martin Thomson wrote: > >From the issue: > > I don't want to see this change to a relative time. That will mess > with our ability to create ServerConfiguration objects that live > outside of the handshake. > > I have no real objection to expanding this to 64bit though. (I'm > personally OK with stating that this is modulo 2^32, but recognize how > that might result in problems.) I got the idea of using 32-bit sequence number arithmetic there too (window is -2G to 2G seconds around current time). I don't suppose any key will need to have TTL of over ~68 years... -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration
On 23 November 2015 at 10:56, Ilari Liusvaara wrote: > I got the idea of using 32-bit sequence number arithmetic there too > (window is -2G to 2G seconds around current time). I don't suppose > any key will need to have TTL of over ~68 years... I did too, but decoded that 2^64 is just easier. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
I support early code point assignment of these curves. Thanks, dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
I support early code point assignment. It’s been suggested that as long as the CFRG signature curves document is not finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything in any draft is subject to change up to the time it’s published and people who implement internet draft should make allowances for such a risk. I see no problem with assigning numbers now. It does not make sense to ship a version of a product that you’ll have to support backwards compatibility with forever. But it is up to implementers to be smart enough about this. Yoav > On 23 Nov 2015, at 4:21 PM, Sean Turner wrote: > > All, > > We’ve received an early code point assignment for the following 4 (four) > elliptic curve points that will go in the "Supported Groups" Registry: > > // ECDH functions. > ecdh_x25519 > ecdh_x448 > > // Signature curves. > eddsa_ed25519 > eddsa_ed448 > > These points will be included in the following 2 (two) drafts: > draft-ietf-tls-tls13 > draft-ietf-tls-rfc4492bis. > > Early code points are permitted in the “Supported Groups” registry and the > chairs (that’s us) need to determine whether there is support for these > assignments. Some input has already been received and those people do not > need to respond again to this call, but we’d like to hear from others whether > they support early code point assignment for these curves. If you do not > please state why. We’re looking for input by November 30th. > > J&S > ___ > 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] Early code point assignments for 25519/448 curves
On 23 November 2015 at 12:56, Yoav Nir wrote: > It’s been suggested that as long as the CFRG signature curves document is not > finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything > in any draft is subject to change up to the time it’s published [...] In your opinion, do you see the semantics of the codepoints changing in any meaningful way? It's one thing to say "accept the risks", but if anyone thinks that there are necessary changes forthcoming, that would give me pause. If everyone says that it's highly unlikely, I'm supportive of the notion that we get a codepoint. Are we happy that we will only be needing the PureEdDSA variants and that no-one will be asking for the HashEdDSA versions? I ask because I've heard it suggested (I think Karthik mentioned this) that we might want to sign the transcript directly in TLS 1.3 rather than rely on collision-resistance of the selected hash function. That would be harder without access to HashEdDSA. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
Hiya, On 23/11/15 14:21, Sean Turner wrote: > All, > > We’ve received an early code point assignment for the following 4 Is the word "request" missing above? Either that or I'm forgetting more than I suspected:-) > (four) elliptic curve points that will go in the "Supported Groups" > Registry: > > // ECDH functions. ecdh_x25519 ecdh_x448 > > // Signature curves. eddsa_ed25519 eddsa_ed448 I think 3 of the above are clearly fine now. I'd suggest holding off on eddsa_ed448 for a while until CFRG are done, but maybe establishing now that there is consensus in the WG to allocate that as soon as CFRG are done (where "done" means folks can implement and interop, not that the RFCs are issued). AFAIK the state of play within CFRG on that is that the chairs plan to do a few polls for the couple of remaining issues in a few weeks, so we're not talking about a major delay and to be fair, CFRG recently have delivered more or less when they said they would. My reason to suggest this is just in case CFRG discover some last minute stuff. While burning a code-point for that wouldn't be a problem, we'd be better off without the confusion. But if (the chairs tell me) there's clear consensus for some other action here, I'll consider myself in the rough and go with that. Cheers, S. > > These points will be included in the following 2 (two) drafts: > draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. > > Early code points are permitted in the “Supported Groups” registry > and the chairs (that’s us) need to determine whether there is support > for these assignments. Some input has already been received and > those people do not need to respond again to this call, but we’d like > to hear from others whether they support early code point assignment > for these curves. If you do not please state why. We’re looking for > input by November 30th. > > J&S ___ 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] Early code point assignments for 25519/448 curves
if it's only a few weeks, let's just do all the signature code points then. -Ekr On Mon, Nov 23, 2015 at 1:38 PM, Stephen Farrell wrote: > > Hiya, > > On 23/11/15 14:21, Sean Turner wrote: > > All, > > > > We’ve received an early code point assignment for the following 4 > > Is the word "request" missing above? Either that or I'm forgetting > more than I suspected:-) > > > (four) elliptic curve points that will go in the "Supported Groups" > > Registry: > > > > // ECDH functions. ecdh_x25519 ecdh_x448 > > > > // Signature curves. eddsa_ed25519 eddsa_ed448 > > I think 3 of the above are clearly fine now. > > I'd suggest holding off on eddsa_ed448 for a while until CFRG > are done, but maybe establishing now that there is consensus in > the WG to allocate that as soon as CFRG are done (where "done" > means folks can implement and interop, not that the RFCs are > issued). > > AFAIK the state of play within CFRG on that is that the chairs > plan to do a few polls for the couple of remaining issues in > a few weeks, so we're not talking about a major delay and to > be fair, CFRG recently have delivered more or less when they > said they would. > > My reason to suggest this is just in case CFRG discover some > last minute stuff. While burning a code-point for that wouldn't > be a problem, we'd be better off without the confusion. > > But if (the chairs tell me) there's clear consensus for some > other action here, I'll consider myself in the rough and go with > that. > > Cheers, > S. > > > > > > These points will be included in the following 2 (two) drafts: > > draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. > > > > Early code points are permitted in the “Supported Groups” registry > > and the chairs (that’s us) need to determine whether there is support > > for these assignments. Some input has already been received and > > those people do not need to respond again to this call, but we’d like > > to hear from others whether they support early code point assignment > > for these curves. If you do not please state why. We’re looking for > > input by November 30th. > > > > J&S ___ 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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> On 23 November 2015 at 12:56, Yoav Nir wrote:
> > It’s been suggested that as long as the CFRG signature curves
> > document is not finalized, we should wait with the eddsa_* ones.
> > I don’t believe so. Anything in any draft is subject to change up
> > to the time it’s published [...]
>
> In your opinion, do you see the semantics of the codepoints changing
> in any meaningful way? It's one thing to say "accept the risks", but
> if anyone thinks that there are necessary changes forthcoming, that
> would give me pause. If everyone says that it's highly unlikely, I'm
> supportive of the notion that we get a codepoint.
My personal view is (I haven't asked Simon about this) is that:
- Ed25519 is currently technically stable. There seems to be consensus
not change it in any way that would break verification.
- Ed448 is unimplementable right now due to two missing functions.
- Once those two are missing (there is call for proposals this
week) functions are decided, Ed448 should become technically
stable.
> Are we happy that we will only be needing the PureEdDSA variants and
> that no-one will be asking for the HashEdDSA versions? I ask because
> I've heard it suggested (I think Karthik mentioned this) that we might
> want to sign the transcript directly in TLS 1.3 rather than rely on
> collision-resistance of the selected hash function. That would be
> harder without access to HashEdDSA.
I would say that using HashEdDSA is a bad idea in that case. HashEdDSA
has fixed "prehash" function and if that hash breaks, the HashEdDSA
scheme breaks (the same is not true w.r.t. hash function for PureEdDSA).
Also, the prehashes might not be the same for Ed25519ph and Ed448ph,
plus I consider interfaces that let one use this dangerous (IUF
signing is dangerous!).
If one wants to have the entiere transcript signed in reasonable way,
one would have to implement hash firewalling at TLS level and require
PureEdDSA.
If doing that, might also be good idea to throw a prefix that screws
many formats ('1E 80 00 00' might be one, it should screw at least ASN.1,
JSON and CBOR).
Also, the absence of indication of PRF hash in the signed data[1] bugs
me, since I need to assume CCR (CR of both hashes does not imply CCR)
in order to show security.
[1] Heck, that indication was in my original proposal (I didn't
quite understand its significance back then).
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
On 23 November 2015 at 14:08, Ilari Liusvaara wrote: > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > plus I consider interfaces that let one use this dangerous (IUF > signing is dangerous!). That suggests that the construction of CertificateVerify is dangerous in the same way, doesn't it? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
On 11/24/15 at 2:08 PM, ilariliusva...@welho.com (Ilari Liusvaara) wrote: My personal view is (I haven't asked Simon about this) is that: - Ed25519 is currently technically stable. There seems to be consensus not change it in any way that would break verification. - Ed448 is unimplementable right now due to two missing functions. - Once those two are missing (there is call for proposals this week) functions are decided, Ed448 should become technically stable. I would prefer not to assign a code point until we know what it means. (i.e. can write code which interoperates.) On 11/23/15 at 2:01 PM, e...@rtfm.com (Eric Rescorla) wrote: if it's only a few weeks, let's just do all the signature code points then. I would like to hear from implementers about how much this delay would affect them. We're coming into the December madness, so perhaps they want to spend time with their families. :-) Otherwise, I'm in favor of early code points. We can always burn ones we dont want. We can either document them as obsolete, do not use, or if deployment is low enough, reassign them later if needed. Cheers - Bill --- Bill Frantz| "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Early code point assignments for 25519/448 curves
On Mon, Nov 23, 2015 at 02:20:15PM -0800, Martin Thomson wrote: > On 23 November 2015 at 14:08, Ilari Liusvaara > wrote: > > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > > plus I consider interfaces that let one use this dangerous (IUF > > signing is dangerous!). > > That suggests that the construction of CertificateVerify is dangerous > in the same way, doesn't it? The problem is that in general, one must not act on invalid data (and IUF signatures positively encourage acting on invalid data), but in case of TLS CertificateVerify, one is expected to act on data, even if invalid, and TLS protocol is designed with that in mind. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
