[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] New curves work and TLS
From:       Ilari Liusvaara <ilariliusvaara () welho ! com>
Date:       2015-10-18 12:25:52
Message-ID: 20151018122552.GA22896 () LK-Perkele-V2 ! elisa-laajakaista ! fi
[Download RAW message or body]

On Sat, Oct 17, 2015 at 07:25:46PM -0400, Sean Turner wrote:
> On Oct 17, 2015, at 08:30, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> > Okay, did a review of draft-ietf-tls-curve25519 (since it still
> > doesn't seem to have been WGLC'd):
> 
> Note that draft-ietf-tls-curve25519 is getting merged into
> draft-ietf-tls-rfc4492bis.

Do we also intend to put CFRG signatures work into that?


Might be a good idea to merge the CFRG work already. The DHFs are
stable. The characteristics of the signature scheme are known well-
enough to already put the needed stuff in (if this is to be done),
even if CFRG draft is still under work.

My thoughts on how CFRG sigs are to be put in:
- Reuse the ECDSA ciphersuites.
- New signature algorithm EdDSA.
- The hash algorithm is always 0 (None), even for Ed25519ph/
  Ed448ph.
- Two new curves, Ed25519 and Ed448, distinct from X25519 and
  X448.
- If new hashes for existing curves are ever defined, those
  will get their own NamedCurve value.
- Reference document specifying new algorithm for putting EdDSA
  public keys into PKIX SPKI.
- All keys and signatures are octet strings with no internal
  structure when handled outside the signing and verification
  functions.
- Don't use Ed25519 keys as Ed25519ph keys (and similarly for
  Ed448/Ed448ph). The CFRG spec specifically warns about this.


And how the existing Curve25519 ECDH draft did things:
- Reuse the ECDHE ciphersuites.
- The X25519/X448 native point format is interpretted as
  "uncompressed".
- Two new curves, X25519 and X448 (different names in that
  draft tho).
- All keys are handled as octet strings with no internal structure
  outside the DHF.
- There are no prefix bytes, so all fields containg public keys
  (ECPoint.point) and the ECDH result Z are both always 32 or 56
  octets.


Also, on reading the document, in numerious place it places the
restriction that RSA end-entity certificate MUST be signed with
RSA and ECDSA end-entity certificate MUST be signed with ECDSA.

Why is this? To me, that kind of thing sounds like a leftover
from TLS 1.1 days, when signature negotiation was a lot less
flexible. It also seems like a special case where uniform
handling would work just fine.

Also, I think it explicitly contradicts TLS 1.2 RFC, which
states that TLS 1.1 did have that restriction and then
notes it is lifted (it also updates RFC4492). 



-Ilari


[prev in list] [next in list] [prev in thread] [next in thread]