Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

2017-12-06 Thread Tony Putman
Hi Hannes, From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com] > [Hannes] It is true that the raw public key RFC does not use long-term ECDH > keys > but instead uses those only in an ephemeral way. I would consider a design > feature rather than a bug. I'm certainly not calling it a

Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

2017-12-06 Thread Tony Putman
Ludwig, Hannes, The differences with RFC7250 are twofold: 1. The raw public keys are not exchanged in the handshake sequence. Even with cached info (RFC7924), a fingerprint of the certificate (or raw public key) is exchanged. Also, a ClientVerify message is needed if mutual authentication is

Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

2017-12-06 Thread Hannes Tschofenig
Hi Tony, If I understand your idea correctly then you have just re-invented the raw public key concept defined in https://tools.ietf.org/html/rfc7250 Ciao Hannes From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Tony Putman Sent: 06 December 2017 14:42 To: ace@ietf.org Subject: [Ace]

Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

2017-12-06 Thread Ludwig Seitz
On 2017-12-06 15:41, Tony Putman wrote: Hi, I recently produced an I-D for a TLS authentication method using pre-shared ECDH asymmetric keys, which I believe will be useful for constrained environments.  IMHO the key benefits are: - a breach of server security does not result in client

[Ace] Independent I-D for new TLS authentication (triple-ECDH)

2017-12-06 Thread Tony Putman
Hi, I recently produced an I-D for a TLS authentication method using pre-shared ECDH asymmetric keys, which I believe will be useful for constrained environments. IMHO the key benefits are: - a breach of server security does not result in client impersonation (unlike PSK) - a single EC

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

2017-12-06 Thread Esko Dijk
Thanks Samuel, I agree with your answers and proposed actions except for the below: > I think the language in section 3 is enough to get robust implementations. > "all claims that are not understood by implementations MUST be ignored." Ignoring a claim is very different from ignoring an

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

2017-12-06 Thread Samuel Erdtman
Thanks Esko for your review it is greatly appreciated. see comments inline On Fri, Dec 1, 2017 at 10:47 AM, Esko Dijk wrote: > Dear all, > > Overall the document looks in good shape to go forward if the earlier > mentioned issue of multiple values for "audience"