[TLS] Harmonizing 4492bis with TLS 1.3

Hi One issue that came up during WGLC for 4492bis is the way EdDSA signatures are mentioned in SignatureAndHashAlgorithm and in In TLS 1.2 and 4492bis we have a SignatureAndHashAlgorithm struct with one byte for hash algorithm and another for signature algorithm.. The HashAlgorithm can be None

[TLS] Pull Request #26 for RFC4492bis

As Sean suggested, this PR removes two paragraphs from the Introduction section. They’re no longer needed in our opinion. https://github.com/tlswg/rfc4492bis/pull/26 If no objections are heard, I will merge this over the weekend. Yoav

Re: [TLS] Harmonizing 4492bis with TLS 1.3

On Tue, Dec 13, 2016 at 01:47:28PM +0200, Yoav Nir wrote: > Hi > > 1. Leave it as its current inconsistent state > 2. Change 4492bis: > a. no new curves for ed25519 and ed448. > b. Two new signature algorithms, and request values 7 and 8 for them. > c. new hash algorithm 0x08 and c

[TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info"

https://github.com/tlswg/tls13-spec/pull/818 Steven Valdez and David Benjamin pointed out that now that we had one code point space we only needed one code point. Target merge date: Thursday -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/m

[TLS] [Editorial Errata Reported] RFC5246 (4885)

The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4885 -

Re: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info"

On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/818 > > Steven Valdez and David Benjamin pointed out that now that we had one code > point > space we only needed one code point. > > Target merge date: Thursday > The structure definition

Re: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info"

Yes. From now on I will try to drink coffee before posting PRs. On Tue, Dec 13, 2016 at 6:54 AM, Ilari Liusvaara wrote: > On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/818 > > > > Steven Valdez and David Benjamin pointed out that now

[TLS] post-handshake auth: multiple CertificateRequests, fewer replies?

4.5.2 Post-Handshake Authentication notes that if a client receives multiple CertificateRequests, it can reply to them in a different order than they were received. By my reading of the text, the client is still "obligated" to respond to all of them (but the server has to be able to receive an arb

Re: [TLS] post-handshake auth: multiple CertificateRequests, fewer replies?

Our implementation considers all post-handshake CertificateRequests to be a fatal error to avoid this. We would do the same even with this proposal; it's an unnecessary complexity (which translates to security risk). If the protocol is such that the client will always bulk-disavow a burst of unexpe

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Thanks to all those that participated in the list discussion, it was a very popular topic. On the list and in the meeting, TLS 1.3 had more support than any other option so we believe there is rough consensus to leave the name of the protocol as TLS 1.3. Thanks, J&S On Sat, Dec 3, 2016 at 10:15

Re: [TLS] Harmonizing 4492bis with TLS 1.3

On 13 December 2016 at 22:47, Yoav Nir wrote: > 2. Change 4492bis: > a. no new curves for ed25519 and ed448. > b. Two new signature algorithms, and request values 7 and 8 for them. > c. new hash algorithm 0x08 and call it something like “intrinsic” This, but with a small tweak: don

Re: [TLS] Harmonizing 4492bis with TLS 1.3

> On 14 Dec 2016, at 3:33, Martin Thomson wrote: > > On 13 December 2016 at 22:47, Yoav Nir wrote: >> 2. Change 4492bis: >> a. no new curves for ed25519 and ed448. >> b. Two new signature algorithms, and request values 7 and 8 for them. >> c. new hash algorithm 0x08 and call it some

Re: [TLS] Harmonizing 4492bis with TLS 1.3

On 14 December 2016 at 16:42, Yoav Nir wrote: > Aren’t we going to have separate registries for 1.2 and 1.3? We don’t want > to force anyone to make the changes you had made (as part of 1.3) just to get > EdDSA..And I need to request things from IANA based on 1.2 registries. Yes, but I was thi