Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt

Hubert Kario writes: > As is described in secion 5.1. of RFC 4492, and then reiterated in > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups) > guides both the ECDH curves and curves understandable by peer for ECDSA > signatures. > > As Curve25519 and Curve448 can only

Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt

Hubert Kario writes: > On Sunday 12 July 2015 16:39:37 Simon Josefsson wrote: >> Hubert Kario writes: >> > As is described in secion 5.1. of RFC 4492, and then reiterated in >> > section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups) >>

Re: [TLS] No cypher overlap

Hubert Kario writes: > On Saturday 01 August 2015 23:16:42 Florian Weimer wrote: >> * Hubert Kario: >> > On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: >> >> In that case, it should be said that a client MUST NOT advertise >> >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ci

Re: [TLS] Adding a new signature scheme

Ilari Liusvaara writes: > This is about adding a new signature primitive (such as the > (eventual) CFRG scheme). I believe these aspects were already discussed in the EdDSA threads. It would be useful to establish consensus around these topics. > There are basically two issues: > > 1) Do we al

Re: [TLS] TLS 1.3 - Support for compression to be removed

Julien ÉLIE writes: > Hi Karthik, > >> It may well be true that some (typically unauthenticated) application >> protocols on top of TLS can survive TLS compression, but it is >> unlikely. > [...] >> HTTP is a particularly bad case because the attacker can potentially >> inject arbitrary data befo

[TLS] Updated EdDSA/Ed25519 PKIX document

Hi all, I have pushed out a new version of the document describing EdDSA public keys, signatures and certificates for PKIX. The change in -03 include the addition of the prehash mode, test vectors generated by GnuTLS, and a section recommending certain human readable names. https://tools.ietf.or

Re: [TLS] Obscure ciphers in TLS 1.3

Dave Garrett writes: > Do either of these obscure ciphers actually get used enough to > continue supporting in TLS 1.3+? (the AEAD versions, not the old > suites that are no longer supported) If the answer is no, can we > prohibit use of them in TLS 1.3+, or at least recommend against them? Came

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

n GnuTLS to pick one encoding over the other looks at the date to see if it fits in a UTCTime value or not. It shouldn't be related to EdDSA. /Simon > -- > James Manger > > > -Original Message- > From: pkix [mailto:pkix-boun...@ietf.org] On Behalf Of Simon Josefss

[TLS] tls-unique

The notes from the interim meeting mentions 'tls-unique' and points to issue #228 on github. I want to get your attention on the draft below. Doesn't it do what you are looking for? There is a little in the way of a problem statement in the TLS interim meeting notes, so it is hard to tell what th

Re: [TLS] tls-unique

Eric Rescorla writes: > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson > wrote: > >> The notes from the interim meeting mentions 'tls-unique' and points to >> issue #228 on github. I want to get your attention on the draft below. >> Doesn't it do wh

Re: [TLS] tls-unique

> > The introduction says: > > > >There exists a TLS extension [I-D.ietf-tls-session-hash] that > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the > > intended properties. If widely implemented and deployed, the > > channel binding type in this document would not offer any

Re: [TLS] tls-unique

Eric Rescorla writes: > On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote: > >> > > The introduction says: >> > > >> > >There exists a TLS extension [I-D.ietf-tls-session-hash] that >> > > modify TLS so that the definition of &#x

[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 Curve

Re: [TLS] Data volume limits

Eric Rescorla writes: > Watson kindly prepared some text that described the limits on what's safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. Can we see a brief writeup explaining the 2^36

Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

Joseph Salowey writes: > Please respond if you have concern about early code point assignment for > the curves listed in draft-ietf-tls-curve25519-01 > . The above draft, and rfc4492bis and tls13-11, has known issues/inconsistencies relat

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

Adam Langley writes: > Curve25519, as the name suggests, operates on 255-bit numbers. When > encoded as bytes, there's obviously a 256th bit that needs to be > specified. > > Curve25519 implementations didn't set the bit but did used to vary on > how they parsed it. Some would take a 256-bit numb

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

tf-tls-rfc4492bis-05 for Curve25519, Curve448, > Ed25519 and Ed448. > > Thanks, > > Joe > > > > > > On 1/12/16, 6:24 AM, "Simon Josefsson" wrote: > > >Adam Langley writes: > > > >> Curve25519, as the name suggests, operates on 2

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

int assignment until then. > > Thanks, > > Joe > (crawling back under my rock now) > > On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov > wrote: > >> >> > On 12 Jan 2016, at 21:31, Ilari Liusvaara >> wrote: >> > >> >> On Tue, Ja

Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

Jonathan Hoyland writes: > When someone tries to copy a message from a SCRAM handshake into some > GSS-API run on a single TLS connection I want to be sure that it will be > rejected, without having to understand exactly how every version of SCRAM > and GSS-API ever (including ones that will be d

Re: [TLS] [Editorial Errata Reported] RFC8422 (5466)

I would also remove the spurious paren instead -- having a MUST NOT inside a paren seems suboptimal to me. /Simon fre 2018-08-17 klockan 14:09 +1000 skrev Martin Thomson: > Looks good.  I would remove the trailing paren instead though. > On Fri, Aug 17, 2018 at 12:08 PM RFC Errata System > wrote

Re: [TLS] [Editorial Errata Reported] RFC8422 (5468)

I think “namedCurve” is better, it matches ASN.1 usage. /Simon > 17 aug. 2018 kl. 04:21 skrev RFC Errata System : > > The following errata report has been submitted for RFC8422, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security > (TLS) Versions 1.2 and Earlier". >