Subject: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt]

From: Aaron Zauner <[email-masked]>
Date: Mon, 01 Jun 2015 14:06:37 +0200

Hi,

With renewed interest on-list w.r.t. efficient single pass AEAD schemes,
I'm happy to update you on the work done for this document.

I'm told over the last couple of months IBM lawyers have been working
hard to come to a consensus if they're willing to exempt IAPM (a
technique OCB mode is based on) from patents for use in TLS. They've
agreed to do this. We've since included all active patents on OCB and
IAPM in the document with a section detailing the current patent
situation of OCB mode for potential use in TLS. I could not reach
Rogaway within the last two weeks so I've included his patents to the
best of my knowledge. This update also features a couple of small
editorial corrections.

There're a few things I'd like to change:

 * I totally agree that having to many ciphersuites is counterproductive
   so I'd like to propose to get rid of PSK ciphersuites in general
   within this document
 * I'd also like to get rid of ECDSA ciphersuites alltogether, ideally
   leaving a few real-world, high-performance ciphersuites to use

Thoughts and feedback apprechiated, diff, HTML et cetera can be accessed
via the quoted mail below.

GitHub: https://github.com/azet/draft-zauner-tls-aes-ocb

Thanks,
Aaron

[email-masked] wrote:
> A new version of I-D, draft-zauner-tls-aes-ocb-03.txt
> has been successfully submitted by Aaron Zauner and posted to the
> IETF repository.
> 
> Name:		draft-zauner-tls-aes-ocb
> Revision:	03
> Title:		AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer Security (TLS)
> Document date:	2015-06-01
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/
> Htmlized:       https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-03
> 
> Abstract:
>    This memo describes the use of the Advanced Encryption Standard (AES)
>    in the Offset Codebook Mode (OCB) of operation within Transport Layer
>    Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and
>    data origin authentication.  The AES-OCB algorithm is highly
>    parallelizable, provable secure and can be efficiently implemented in
>    software and hardware providing high performance.  Furthermore, use
>    of AES-OCB in TLS is exempt from past IPR claims by various parties.
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Jun 2015 05:29:52 -0700

>    leaving a few real-world, high-performance ciphersuites to use

I don't understand this point: ECDSA cipher suites are the ones with the
best performance at present.

-Ekr

> > URL:
> https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-03.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-03
> >
> > Abstract:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 01 Jun 2015 14:37:16 +0200

Hi Ekr,

Eric Rescorla wrote:
> On Mon, Jun 1, 2015 at 5:06 AM, Aaron Zauner <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Firstly, as far as I know it's also quite difficult to get ECDSA
certificates in the wild. Has this changed significantly over the past
couple of months? Second - there's a current draft on EdDSA, which I'd
prefer over ECDSA, if somehow possible. I'm more about minimizing the
list of cipher-suites this draft introduces than to point out that I
dislike a particular signature schemes.

Aaron

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Jun 2015 05:47:08 -0700

On Mon, Jun 1, 2015 at 5:37 AM, Aaron Zauner <[email-masked]> wrote:

> couple of months?

They certainly do exist. For instance, I'm connected to Google with one now.
I believe Let's Encrypt also intends to issue for ECDSA.

> Second - there's a current draft on EdDSA, which I'd
> prefer over ECDSA, if somehow possible.

Well, the CFRG hasn't decided on next-gen signature schemes, so I expect
that any standardization of EdDSA is going to take a while. Also, it seems
at least possible that it will still use an ECDSA cipher suite name.

-Ekr

I'm more about minimizing the

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 1 Jun 2015 15:53:02 +0300

> dislike a particular signature schemes.

Well, in TLS 1.2 (and editor's copy 1.3), one could maybe get away with
just specifiying (EC)DHE_CERT ciphersuites, leaving certificate
negotiation to extension.

I think the current plan with EdDSA and related certficates are to reuse
ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate.

With DH and ECDH codepoints, merging those is not possible in TLS 1.2.
This is because DH would need parameters which don't exist for ECDH,
and ECDH length field is insufficient for DH.

Such merger could be possible for TLS 1.3, since DH has sufficient
length field and does not require parameters not present for ECDH.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Mon, 01 Jun 2015 14:54:06 +0200

> certificates in the wild. Has this changed significantly over the past

yes, it has. If you ask specifically for them, you can get ECDSA certs signed 
by ECDSA roots. About 5% of servers in Alexa top 1 million use ECDSA certs 
trusted by Firefox.

> dislike a particular signature schemes.

for now it looks like it will use ECDSA codepoints, it will just use signature 
algorithms extension to switch ECDSA to EdDSA.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 01 Jun 2015 15:05:05 +0200

Hi,

Thanks for all the fast replies.

Ok. I won't touch ECDSA in my document for the time being.

The PSK cipher-suites still bother me. I'm not sure I want to support
them. While RFC6655 (CCM) specifies PSK cipher-suites, RFC5288 (GCM)
does not. These are currently included in my draft because Nikos and
Peter Gutmann suggested including them.

Aaron

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 1 Jun 2015 11:53:47 -0400

On Mon, Jun 1, 2015 at 9:05 AM, Aaron Zauner <[email-masked]> wrote:
> ...
What do you suggest for resource constrained devices? What are the
remaining choices?

When the device cannot do public key, they often use PSK.

PSK also has two desirable properties: channel binding and mutual
authentication, and most other cipher suites don't provide them.

Jeff

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 01 Jun 2015 18:06:56 +0200

Hi,

> What do you suggest for resource constrained devices? What are the

There're none.

> authentication, and most other cipher suites don't provide them.

I agree, but am unsure to what extent they are used in real life. I'm
trying to reduce the number of cipher-suites that would have to be added
to the IANA TLS parameter list; since PSK is unsupported with GCM
cipher-suites it seems only logical to exclude them here as well.
Because I regularly receive off-list mail that PSK is indeed wanted,
I've not yet removed those cipher-suites.

RFC3268 (CBC modes) also excludes TLS-PSK ciphersuites. There seems to
be a seperate document that deals with TLS-PSK namely RFC5487 (defines
GCM and CBC PSK cipher-suites). It might make sense to update this
document in case OCB mode get's accepted by the TLS-WG instead.

BTW: is TLS-SRP in use anywhere?

Aaron

---

From: Peter Bowen <[email-masked]>
Date: Mon, 1 Jun 2015 09:15:59 -0700

> cipher-suites it seems only logical to exclude them here as well.

Some TLS implementations (notably BoringSSL) have ended up assigning
non-standard ciphersuites ECDHE+PSK+AES-GCM for this very reason.  I
think the lack of this combination is more of an oversight than
anything.

Thanks,
Peter

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 01 Jun 2015 18:23:22 +0200

> think the lack of this combination is more of an oversight than

Unsure if RFC5478 got introduced after the fact, but this document seems
to be the one defining those cipher-suites. In addition it defines PSK
cipher-suites in CBC-mode using SHA256+.

https://tools.ietf.org/html/rfc5487

This is all quite confusing and spread over a lot of different
documents. PSK in CBC-mode (with < SHA256) for example is a different
document (RFC4279).

I'll leave it up to long-time TLS-WG members to decide where these PSK
cipher-suites /would/ fit best. I'm not sure that this document is the
right place -- but that's only because, in the past, PSK cipher-suite
were dealt with exclusively in separate documents as it seems.

Aaron

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Jun 2015 12:29:19 -0400

> ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate.

When we were doing to work for RSA PKCS #1 v1.5, OAEP, and PSS, it was unclear whether using the same key pair with all of these schemes would lead to trouble.  For this reason, the certificate can allow the key pair to be used for just on or all of them.

The same question needs to be asked here.  I hope a more definitive answer becomes available this time.

Russ

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 1 Jun 2015 12:30:49 -0400

> I've not yet removed those cipher-suites.

I know hoteliers are working with lock vendors on the next generation
of locks. These are the online, no-mag-and-stripe keys and locks. I
imagine PSK is going to be one of their expected choices due to
constraints.

Folks like Dr. Gutmann have use cases I am not familiar with. (or have
not yet suffered).

> BTW: is TLS-SRP in use anywhere?

I believe so. It looks like World of Warcraft/Blizzard uses them
(http://arstechnica.com/security/2012/08/hacked-blizzard-passwords-not-hard-to-crack/).
I also believe Cupid Media was using them
(https://news.ycombinator.com/item?id=6767152).

If PSK is going to be yanked, then there should probably be an
non-public-key PAKE alternative.

Jeff

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 01 Jun 2015 20:07:35 +0300

> non-public-key PAKE alternative.

Hi Jeff,

PAKE means password-authenticated key exchange, and TLS-PSK is not 
suitable for use with (short, memorable) passwords. See 
https://tools.ietf.org/html/rfc4279#section-7.2

TLS-SRP is the right tool for that. It is public key based but does not 
require the whole PKI code bloat, so may be a good fit for 
resource-constrained devices.

Thanks,
	Yaron

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 1 Jun 2015 13:22:03 -0400

On Mon, Jun 1, 2015 at 1:07 PM, Yaron Sheffer <[email-masked]> wrote:
> PAKE means password-authenticated key exchange, and TLS-PSK is not suitable
> for use with (short, memorable) passwords. See
Indeed, thanks. Sorry about that.

Jeff

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Jun 2015 13:28:22 -0400

> certificates in the wild. Has this changed significantly over the past

I've heard this claim in the past, but i'm not sure what it is based on.
AFAICT, there are several public CAs who are happy to issue ECDSA
certificates if you ask them for them.

In November 2014, i managed to get one from Comodo (or a Comodo
reseller, i can't keep all the "imprints" and "branding" straight) and
it took about 20 minutes from start to finish.

Can you describe how you have tried to get an ECDSA cert, and how those
attempts failed?

             --dkg

---

From: Michael StJohns <[email-masked]>
Date: Mon, 01 Jun 2015 13:48:36 -0400

> ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate.
I may be misreading this and all you're talking about are code points 
for TLS, but in case you're talking about the more specific issue of 
reusing the current SubjectPublicKeyInfo definitions of id-ecPublicKey 
for certificates containing EdDSA public keys:

RFC 5480 defines the format of an EC public key (as identified by 
1.2.840.10045.2.1 and for that matter by 1.3.132.1.12 and 
1.3.123.1.13).  Note specifically the second bullet on the format of the 
ECPoint octet string.

> 2.2.  Subject Public Key
>
>     The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
>     ECC public keys have the following syntax:
>
>       ECPoint ::= OCTET STRING
>
>     Implementations of Elliptic Curve Cryptography according to this
>     document MUST support the uncompressed form and MAY support the
>     compressed form of the ECC public key.  The hybrid form of the ECC
>     public key from [X9.62] MUST NOT be used.  As specified in [SEC1]:
>
>        o The elliptic curve public key (a value of type ECPoint that is
>          an OCTET STRING) is mapped to a subjectPublicKey (a value of
>          type BIT STRING) as follows: the most significant bit of the
>          OCTET STRING value becomes the most significant bit of the BIT
>          STRING value, and so on; the least significant bit of the OCTET
>          STRING becomes the least significant bit of the BIT STRING.
>          Conversion routines are found in Sections 2.3.1 and 2.3.2 of
>          [SEC1].
>
>        o The first octet of the OCTET STRING indicates whether the key is
>          compressed or uncompressed.  The uncompressed form is indicated
>          by 0x04 and the compressed form is indicated by either 0x02 or
>          0x03 (see 2.3.3 in [SEC1]).  The public key MUST be rejected if
>          any other value is included in the first octet.

This RFC mirrors equivalent language in both X9.62/63 and the SecG stuff 
(and for that matter NIST).

So, don't try and overload the current meaning of id-ecPublicKey - 
you'll break a *lot* of things.  And we (the IETF that is) don't 
actually have change control over what that OID means.

Instead, get a new allocation and write a document that looks like 
RFC5480 for the ED and Curve public keys.  You want certificate 
representations for *both*.

Later, Mike

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 1 Jun 2015 11:33:16 -0700

> On Jun 1, 2015, at 10:28 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

I tried to get one from Comodo about a year ago.  It wasn’t advertised on their website but I asked one of their tech support folks.  They said that it was an experimental feature for business customers only, and would cost me something like $600.  I don’t remember if that was a 1-year or 3-year cert.

I looked at Verisign’s catalog as well, and it was labeled as an enterprise feature with an even higher price tag.  Low thousands I think.  I asked the guys at BaySec and they said that this was the shape of the market at that time.

I also looked at StartSSL.  They are free, but only offer RSA certs.  I mostly wanted ECDSA for performance on a super slow home server, and I figured $600 in hardware upgrades would go a lot further than $600 in certs.

Anyway you can get ECDSA certs relatively easily, but not cheaply; or at least, that’s how it was a year ago.

— Mike

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Jun 2015 15:13:02 -0400

On Mon 2015-06-01 14:33:16 -0400, Michael Hamburg wrote:
> I tried to get one from Comodo about a year ago.  It wasn’t advertised
> on their website but I asked one of their tech support folks.  They
> said that it was an experimental feature for business customers only,
> and would cost me something like $600.  I don’t remember if that was a
> 1-year or 3-year cert.

I just went back through my notes: in November 2014, i used a small
(~$5?) credit i had with https://ssls.com/ to get a PositiveSSL Comodo
cert with ECC.  I couldn't figure out how to submit the ECC cert through
the https://ssls.com/ web interface, so i opened their "live support"
chat, and got this suggestion:

>>> Unfortunately our system cannot parse ECDSA public keys. As an
>>> option you can purchase the cert here and you would need to submit a
>>> ticket to us for the manual cert activation.

>>> To submit a ticket, please follow this link:
>>> https://support.cheapssl.com/index.php?/cheapssl/Tickets/Submit
>>> Please provide the cert or order ID, the request and approver and
>>> admin contacts in the ticket

I did that, and the confirmation e-mail came through about a half-hour
later.

> at least, that’s how it was a year ago.

I found it was quick and cheap, but the UI/UX was not as streamlined as
I wanted it to be for a DV cert (i had to nag two humans, via chat and
the ticket system to make it happen, but it did happen promptly).

ymmv, of course,

  --dkg

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 01 Jun 2015 22:12:42 +0200

Hi dkg,

> Can you describe how you have tried to get an ECDSA cert, and how those

My last attempt must have been a year or more ago. That's absolutely
subjective and from what I've heard from other operators (similar
experiences to those described by mike hamburg). Since people were nice
enough to inform me in this thread that, indeed, ECDSA is getting
deployed (as seen in Kario's statistics) and will be used for let's
encrypt - I have no problem keeping it in the document!

Aaron

---

From: Rob Stradling <[email-masked]>
Date: Mon, 01 Jun 2015 21:46:04 +0100

On 01/06/15 19:33, Michael Hamburg wrote:
<snip>
> I tried to get one from Comodo about a year ago.  It wasn’t advertised on their website but I asked one of their tech support folks.  They said that it was an experimental feature for business cust…

Hi Mike.  It's true that we haven't made a big deal of advertising the 
fact that we are happy to certify EC public keys and sign using ECDSA 
these days.

I'm rather puzzled by your experience with our tech support guys though. 
  It's never been an "experimental feature for business customers only". 
  And we don't set different prices for EC certs compared to RSA certs.

If you place an order directly with Comodo, and provide a CSR containing 
an EC public key (secp256r1, secp384r1 or secp521r1), then the resulting 
cert will be signed using ECDSA.  Simple as that.  It should be equally 
simple if you order via a Comodo reseller, but as DKG said, YMMV.  (I'm 
guessing that some reseller systems might feel the need to attempt to 
parse the CSR...and fail because they're not ECC-ready).

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 1 Jun 2015 16:34:45 -0700

Hi Rob,

I guess I’m misremembering my interaction with another CA as Comodo.  Sorry about that.  I don’t have a note of which CAs I tried other than Verisign and StartSSL, so I can’t check for sure.

— Mike

> On Jun 1, 2015, at 1:46 PM, Rob Stradling <[email-masked]> wrote:
> 
> Hi Mike.  It's true that we haven't made a big deal of advertising the fact that we are happy to certify EC public keys and sign using ECDSA these days.
> 
> I'm rather puzzled by your experience with our tech support guys though.  It's never been an "experimental feature for business customers only".  And we don't set different prices for EC certs compared to RSA certs.
> 
> If you place an order directly with Comodo, and provide a CSR containing an EC public key (secp256r1, secp384r1 or secp521r1), then the resulting cert will be signed using ECDSA.  Simple as that.  It should be equally simple if you order via a Comodo reseller, but as DKG said, YMMV.  (I'm guessing that some reseller systems might feel the need to attempt to parse the CSR...and fail because they're not ECC-ready).
>

---

From: Gunnar Wolf <[email-masked]>
Date: Mon, 1 Jun 2015 20:46:53 -0500

> dislike a particular signature schemes.

I'd venture to say that's a consequence of them having been around
much less time than the other schemes; not only have had crypto
libraries to gain widespread support for them to be interoperable
enough, but also the involved individuals/companies (mostly thinking
about CAs.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 06 Jun 2015 04:04:09 +0200

Russ Housley <[email-masked]> writes:

> When we were doing to work for RSA PKCS #1 v1.5, OAEP, and PSS, it was
> unclear whether using the same key pair with all of these schemes
> would lead to trouble.  For this reason, the certificate can allow the
> key pair to be used for just on or all of them.
>

Is that really comparable?  All RSA signature schemes use the same RSA
private keys.  For ECDSA and EdDSA this is not the case.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 06 Jun 2015 04:06:52 +0200

> representations for *both*.

I've started this for EdDSA:
https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00

Are you saying it would be useful to also specify certificate formats
for Curve25519 ECDH keys?

/Simon

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 6 Jun 2015 02:21:17 +0000

> Are you saying it would be useful to also specify certificate formats for
> Curve25519 ECDH keys?

It's probably just me being dumb, but how could this be useful?

---

From: Peter Bowen <[email-masked]>
Date: Fri, 5 Jun 2015 20:00:19 -0700

> It's probably just me being dumb, but how could this be useful?

I think the topic was not ECDH keys but documenting how to use EdDSA
to sign PKIX/X.509 certificates and to have Curve25519 public keys in
certificates to use with EdDSA in TLS (for auth).

So something analogous to RFC 3279 sections 2.2.3 and 2.3.5.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 10 Jun 2015 13:27:17 -0400

> for Curve25519 ECDH keys?

Sorry - I missed this in the pile.

And yes for Curve25519.

Here's my thoughts:

Usually, you have a certificate with a public key in it that's used to 
sign an ephemeral (EC)DH public key.  The EPK is used to derive a shared 
secret and everything downstream is derived from that.   The session 
keys trace their authentication back through the shared secret, through 
the EPK and through the signature over the EPK to the certificate's 
public key.   And the public key in the certificate chains back to some 
root.

With key agreement keys such as ECDH, Curve25519 or DH, what you can do 
instead is to use the key in the certificate with the other side's 
certificate key, to derive one half of the total shared secret and the 
senders EPK with the receiver's ephemeral private key to derive the 
second half.  Concatenate those and then derive your downstream keys 
from them.

(e.g.  ECDH (PermPrivate1, PermPublic2) || ECDH (EphemPrivate1, 
EphemPublic2) )

The certificate keys chain as before, so that you know that the first 
half of the shared secret is derived from authentic data and is itself 
authentic.  Combining the first half of the shared secret with the 
second half still gives you authentic data (but results in a varied 
shared secret for each call).  And that means downstream keys derived 
from the combined shared secrets can still be traced back to the 
certificate authentication root.

The nice thing about this scheme (It's called a C(2,2) scheme in NISP 
SP800-56A parlance), is that you don't need to sign anything during a 
key agreement handshake.  You still need traditional signature schemes 
over the certificates, but you don't actually need them in the handshake.

There are other schemes where one side only has ephemeral keys (e.g. 
client without cert) where this still works - you end up with:

ECDH (PermPrivate1, EphemPublic2) || ECDH (EphemPrivate1, EphemPublic2)

This just works with the existing EC Prime and F2M curves as the key 
pairs can be used with both ECDSA and ECDH.

In any event, going ahead and creating a certificate format for 
Curve25519 at the same time you do ED25519 probably makes sense given 
the two algorithms are family members and appear to share a representation.

Mike

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jun 2015 22:20:21 -0500

On Wed, Jun 10, 2015 at 01:27:17PM -0400, Michael StJohns wrote:
> [...]
> The nice thing about this scheme (It's called a C(2,2) scheme in
> NISP SP800-56A parlance), is that you don't need to sign anything
> during a key agreement handshake.  You still need traditional
> signature schemes over the certificates, but you don't actually need
> them in the handshake.

RSA key transport was nice because it was faster than DH + signatures.

Now that PFS matters that consideration goes the way of the dodo.  It's
got to be key agreement + authentication, which means either key
agreement with signatures, or two key agreements.

(Using DH with fixed public keys goes back to the invention of DH
itself, and this was deployed way back when.  E.g., AUTH_DH.  This is
why PKIX supports key agreement certificates.  Combining DH for
authentication with DH for PFS is an obvious idea.)

And besides, with ECC and curves like Curve25519, *two* ECDH exchanges,
one of which has a certified public key on the server side (the other
being ephemeral, for some value of "ephemeral"), can go faster than one
signed ECDH exchange.  How much, if at all, may depend on what curves
and implementations.

> client without cert) where this still works - you end up with:

Right, and which would be the common case on the Internet.

> pairs can be used with both ECDSA and ECDH.

Is that safe?

> Curve25519 at the same time you do ED25519 probably makes sense
> given the two algorithms are family members and appear to share a
> representation.

Sure, but doing it separately works too.  Whatever makes the spec go
faster.

Nico
--