Re: [TLS] Was the numbering of rsa_pss_pss_sha384 intentional?

2018-01-03 Thread Martin Thomson
https://github.com/tlswg/tls13-spec/pull/1133 On Thu, Jan 4, 2018 at 12:32 PM, Eric Rescorla wrote: > No, just forgetting we were working in hex I think it would be fine to > change. > > -Ekr > > > On Wed, Jan 3, 2018 at 5:04 PM, Martin Thomson > wrote: >> >> rsa_pss_pss_sha256(0x0809), >> rsa_p

Re: [TLS] Was the numbering of rsa_pss_pss_sha384 intentional?

2018-01-03 Thread Eric Rescorla
No, just forgetting we were working in hex I think it would be fine to change. -Ekr On Wed, Jan 3, 2018 at 5:04 PM, Martin Thomson wrote: > rsa_pss_pss_sha256(0x0809), > rsa_pss_pss_sha384(0x0810), > rsa_pss_pss_sha512(0x0811), > > 0x080a is the next value... > > __

[TLS] Was the numbering of rsa_pss_pss_sha384 intentional?

2018-01-03 Thread Martin Thomson
rsa_pss_pss_sha256(0x0809), rsa_pss_pss_sha384(0x0810), rsa_pss_pss_sha512(0x0811), 0x080a is the next value... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

2018-01-03 Thread Colm MacCárthaigh
On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario wrote: > > > *Second: hide all alerts in suspicious error cases* > > Next, when the handshake does fail, we do two non-standard things. The > > first is that we don't return an alert message, we just close the > > connection. > > > > *Third: mask timing

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Benjamin Kaduk
On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: > Judging from TLS1.3's problems with middleboxes, content filtering isn't so > rare, especially in the corporate world. > > The provider of filtering services (for example OpenDNS) / middlebox > manufacturer would have to recognize if the client suppo

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Mateusz Jończyk
W dniu 03.01.2018 o 17:08, Russ Housley pisze: > Mateusz: > > How do you see IANA controlling which parties get certificates for the > access_administratively_disabled.net domain? IANA is just an example, there could be some other provider controlling the access_administratively_disabled.net dom

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Mateusz Jończyk
W dniu 03.01.2018 o 17:31, Eric Rescorla pisze: > > > On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > Well, this seems like the first arm, in which you change the browser, > so the > > questi

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Eric Rescorla
On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk wrote: > W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk > > wrote: > > > > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > > I have several comments:

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Mateusz Jończyk
W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > I have several comments: > > > > - This is almost entirely out of scope for TLS, so yo

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Russ Housley
Mateusz: How do you see IANA controlling which parties get certificates for the access_administratively_disabled.net domain? Russ P.S. If I recall RFC 1034 and 1035 correctly, domain name labels may contain only letters, digits, and hyphen. Underscore is not allowed. > On Jan 3, 2018, at 7

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Eric Rescorla
On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk wrote: > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > I have several comments: > > > > - This is almost entirely out of scope for TLS, so you should start with > > CAPPORT. If they're interested, then we can discuss the code point > assignmen

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Mateusz Jończyk
W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > I have several comments: > > - This is almost entirely out of scope for TLS, so you should start with > CAPPORT. If they're interested, then we can discuss the code point assignment > in > TLS. > > - You point #2 would effectively require either

[TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt

2018-01-03 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : IANA Registry Updates for TLS and DTLS Authors : Joe Salowey Sean Turner

Re: [TLS] access_administratively_disabled v2

2018-01-03 Thread Eric Rescorla
I have several comments: - This is almost entirely out of scope for TLS, so you should start with CAPPORT. If they're interested, then we can discuss the code point assignment in TLS. - You point #2 would effectively require either changes to the browser or CA issuance policies (the BRs would pro

[TLS] access_administratively_disabled v2

2018-01-03 Thread Mateusz Jończyk
Hello, Based on Your feedback (for which I am grateful) I have designed a new version of the access_administratively_disabled mechanism. 1. One new AlertDescription value should be specified: access_administratively_disabled. 2. The information why the webpage is blocked is specified at the URL h

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

2018-01-03 Thread Hubert Kario
On Friday, 15 December 2017 19:07:16 CET Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is > broken, we're in serious trouble, but that's largely because of the fact > that that's what people's certificates have, so clients really can't refuse > to support

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

2018-01-03 Thread Hubert Kario
On Thursday, 14 December 2017 23:20:54 CET Colm MacCárthaigh wrote: > Based on our experiences with all of this over the last few weeks, I'd like > to summarize and throw out a few suggestions for making TLS stacks more > defensive and robust against problems of this class. One or two may be even >