Re: [TLS] Fwd: Updated elliptic curve drafts

On Mon, Oct 12, 2015 at 10:47:58PM +0200, Simon Josefsson wrote: > > The following document adds new EdDSA key/signature OIDs directly: > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 The certificate example seems to contain OID 1.3.101.100.1... Is that intended or should it be 1.3

Re: [TLS] I-D: CipherSuites for Kerberos + DH

Hello Benjamin, > This would seem to require an application protocol doing some Kerberos > exchanges up front to establish the Kerberos session key before pivoting > into TLS-PSK in a STARTLS-esque fashion. If that's what the application > protocol would look like, it seems like there's no reason

Re: [TLS] I-D: CipherSuites for Kerberos + DH

Hello Ilara / Watson / TLS WG, Thanks again, If I was to do things like the current proposal (as opposed to overloading DHE-PSK), I would put in hash of entiere client and server first flights. Now I see what you mean. Indeed, the master secret used in Finished does not take it into account in

Re: [TLS] I-D: CipherSuites for Kerberos + DH

On 10/11/2015 08:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: >> Some quick comments: >> - The signed DH share does not look to be bound to anything (crypto >> parameters negotiation, randoms, server key exchange, etc..). I can't >> offhand say what tha

[TLS] Fwd: Updated elliptic curve drafts

FYI -- posted to p...@ietf.org. Intended to work together with draft-josefsson-tls-eddsa or draft-josefsson-tls-eddsa2. /Simon From: Simon Josefsson Subject: Updated elliptic curve drafts To: p...@ietf.org Date: Mon, 12 Oct 2015 22:25:31 +0200 Hi, I've updated my drafts on Curve25519/Curve448

Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

Yes, my fault. From: Quynh Dang mailto:quyn...@gmail.com>> Date: Monday 12 October 2015 19:02 To: John Mattsson2 mailto:john.matts...@ericsson.com>> Cc: "TLS@ietf.org" mailto:TLS@ietf.org>>, Sean Turner mailto:s...@sn3rd.com>> Subject: Re: [TLS] TLS 1.3 Recommended ECC curve

Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

Hi John, Sha384 in the ciphersuite is the hash function to be used in hmac, not signatures, and the security of this hmac depends on the strenght of the hmac key and the tag size. Regards, Quynh. On Oct 12, 2015 12:50 PM, "John Mattsson" wrote: > The statement i [1] is about AES, and is very tr

Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

The statement i [1] is about AES, and is very true. AES-192 is very seldom used, and people tend to jump directly to AES-256. For ECC curves, the opposite is true, people tend to use P-384 instead of P-521. Most likely because of that P-384 is used in suite B. According to [2], Google Chrome recen

Re: [TLS] TRON workshop

On Mon, Oct 12, 2015 at 08:04:37AM -0700, Eric Rescorla wrote: > On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara > wrote: > > > > 1) It seems to me that if server key is compromised, MITM can > > substitute 0-RTT data with its own (at least if original and modified > > one have the same number of

Re: [TLS] TRON workshop

On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara wrote: > On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > > > > > aren't we still missing the 0-RTT mode? > > > > It's in the current draft though there are a few details tha

Re: [TLS] TRON workshop

On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > > > aren't we still missing the 0-RTT mode? > > It's in the current draft though there are a few details that we're > going to need to nail down over the next few weeks and in

Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt

In summary: +1 to Viktor’s argument. -1 to Dave’s. -- Regards, Uri Blumenthal On 10/11/15, 22:41, "TLS on behalf of Dave Garrett" wrote: >On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote: >> There's no reason for pessimism > >Sorry, I have to laugh a bit here. :p > >> we're not

Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

It is interesting to note that in discussing update IPSec’s RFC 4307 somebody suggested making 192 a MAY because folks only use 128/256 [1]. spt [1] http://mailarchive.ietf.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE On Oct 12, 2015, at 05:01, John Mattsson wrote: > I think the selection o

Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt

On Sunday 11 October 2015 19:13:03 Dave Garrett wrote: > On Sunday, October 11, 2015 05:58:59 pm Viktor Dukhovni wrote: > > Pointless restrictions lead to fallback to even worse choices. > > And no restrictions lead to horrible fallback choices. Running under > the assumption that some population

Re: [TLS] TRON workshop

On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote: > > Hiya, > > > > First, thanks all for all your ongoing work on TLS1.3. I'm sure we're > > all aware that this is important stuff that needs to be, and is being, > > done carefully

Re: [TLS] TRON workshop

On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote: > Hiya, > > First, thanks all for all your ongoing work on TLS1.3. I'm sure we're > all aware that this is important stuff that needs to be, and is being, > done carefully with due attention to security analysis. > > Early in the process

Re: [TLS] I-D: CipherSuites for Kerberos + DH

On Mon, Oct 12, 2015 at 07:14:05AM +0200, Rick van Rein wrote: > Hello, > > Thanks for the feedback. Responding to it: > > Ilari> - The signed DH share does not look to be bound to anything (crypto > Ilari> parameters negotiation, randoms, server key exchange, etc..). > > This is indeed ea

Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

From: Michał Staruch mailto:m...@cinkciarz.pl>> Date: Monday 12 October 2015 11:34 To: John Mattsson2 mailto:john.matts...@ericsson.com>> Cc: "TLS@ietf.org" mailto:TLS@ietf.org>> Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security >We already have "SHOULD

Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security

We already have "SHOULD support key exchange with X25519" in this section, so people implementing it should have no problems with adopting X448 to achieve ~224 bit security where it's needed (and better performance than P-384). On

[TLS] TLS 1.3 Recommended ECC curve for 192-bit security

I think the selection of MTI Cipher Suites (Section 8.1 of draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended ECC curve for the “SHOULD” cipher suites. Little benefit of using AES-256 with P-256 or curve25519. Shouldn’t there be a SHOULD implement ECC curve giving at least 19