Re: [TLS] Controlling use of SHA-1

On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote: > On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > > Whether SHA-1 in the chain is used to make trust decisions is only > > known to the client, and the server MUST NOT preempt that by denying > > the client access to

Re: [TLS] Comments from CELLOS consortium

Dear Sean, Eric, Dave, and all, We appreciate much kind treatment for our comments at GitHub on the following items. CELLOS: AEAD-1/2 CELLOS: 0-RTT 1/2/3 CELLOS: Resumption & PSK 2 CELLOS: KDF CELLOS: SharedSecret CELLOS: ClientAuthentication CELLOS: HelloRetryRequest With Best Regards, Shin’ic

Re: [TLS] Allow NamedGroups from the server?

On Wed, Oct 21, 2015 at 5:29 PM, Dave Garrett wrote: > On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/292 > > > > Presently, RFC 4492 only specifies the EC points it can support in > > ServerHello, but does not let the server indicat

Re: [TLS] Allow NamedGroups from the server?

On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/292 > > Presently, RFC 4492 only specifies the EC points it can support in > ServerHello, but does not let the server indicate which EC curves it > supports. Unless I'm missing something, t

Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

Congrats on releasing an RFC that has day one 100% server support. :p Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > Whether SHA-1 in the chain is used to make trust decisions is only > known to the client, and the server MUST NOT preempt that by denying > the client access to whatever chain it has on hand. Can we please just fix this issue prop

Re: [TLS] Allow NamedGroups from the server?

If it's true that the only use of this indication is client auth, then option 1 makes the most sense to me. -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: Wednesday, October 21, 2015 5:01 PM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TL

Re: [TLS] Allow NamedGroups from the server?

2b. encrypted extensions over ServerHello If we make this like signature_algorithms, then I think that I prefer option 1. I don't like that signature_algorithms is built that way, I think that it's repulsive, but there are some advantages to doing it that way, especially if we accept the fact tha

[TLS] Allow NamedGroups from the server?

https://github.com/tlswg/tls13-spec/issues/292 Presently, RFC 4492 only specifies the EC points it can support in ServerHello, but does not let the server indicate which EC curves it supports. Unless I'm missing something, this means that there's no way for the server to indicate what groups it wo

Re: [TLS] Controlling use of SHA-1

I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, but I think it's better than the alternative. Dave On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote: > I think this

Re: [TLS] Remove extra 0-RTT content types

On Wed, Oct 21, 2015 at 3:56 PM, Martin Thomson wrote: > On 21 October 2015 at 15:52, Eric Rescorla wrote: > > I don't think this will make the implementation that hard :) > > Yeah, you have to actually pay attention to the early_data extension. > That might not be a bad thing in the end. > Yes

Re: [TLS] Remove extra 0-RTT content types

On 21 October 2015 at 15:52, Eric Rescorla wrote: > I don't think this will make the implementation that hard :) Yeah, you have to actually pay attention to the early_data extension. That might not be a bad thing in the end. ___ TLS mailing list TLS@ie

Re: [TLS] Remove extra 0-RTT content types

On Wed, Oct 21, 2015 at 3:52 PM, Martin Thomson wrote: > I'm not sure that I follow. Are all the records in 0RTT going to use > a content of handshake, or just the > Certificate/CertificateVerify/Finished? I assume that you meant just > the handshake messages, in which case yes, this is OK. Y

Re: [TLS] Remove extra 0-RTT content types

I'm not sure that I follow. Are all the records in 0RTT going to use a content of handshake, or just the Certificate/CertificateVerify/Finished? I assume that you meant just the handshake messages, in which case yes, this is OK. It does make identification of what goes into the handshake hash ma

[TLS] Remove extra 0-RTT content types

https://github.com/tlswg/tls13-spec/issues/311 I initially added this to make it easier to determine the end of the 0-RTT handshake if the server had forgotten the key, but with content type encryption this is no longer relevant. I propose we remove this and simply use Handshake here, allowing the

Re: [TLS] New Version Notification for draft-cairns-tls-session-key-interface-01.txt

Hi, Please find our new version from of the Session Key Interface for TLS and DTLS. The main motivation for this interface is that the private key is centralized in a Key Server instead of being distributed and copied among the Edge Servers. All cryptographic operation are performed by the Key

Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

On 21 October 2015 at 13:43, wrote: > RFC 7685 > > Title: A Transport Layer Security (TLS) > ClientHello Padding Extension That took longer than I expected. Nice work. ___ TLS mailing list TLS@ietf.org https:/

[TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

A new Request for Comments is now available in online RFC libraries. RFC 7685 Title: A Transport Layer Security (TLS) ClientHello Padding Extension Author: A. Langley Status: Standards Track Stream: IETF

Re: [TLS] Controlling use of SHA-1

On 21 October 2015 at 12:56, Viktor Dukhovni wrote: > Each peer MUST try to send a chain that matches an advertised > signature algorithm if it has a choice of chains, but otherwise > MUST send whatever it has. Do, or do not. There is no try. It's not like any of this is ambiguous in any way.

Re: [TLS] Controlling use of SHA-1

On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely. Forbidding the sending of SHA-1 chains was wrong last time we discussed this at length, and remains wrong now. Whet

Re: [TLS] Controlling use of SHA-1

I am in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not advertise SHA-1. IMHO it would be best to not allow the server to send certs using any algorithms that don’t agree with signature_algorithms, as TLS 1.2 did. But this is a step in the ri

Re: [TLS] HelloRetryRequest and stateless reject

On 21 October 2015 at 12:29, Ilari Liusvaara wrote: > Bit crazy idea: Have vector of causes handshake went wrong > (e.g. required share missing, cookie required). Then the > client verifies that that: > - There is at least one cause > - All causes are known (can't retry with unknown error) > - All

Re: [TLS] HelloRetryRequest and stateless reject

On Wed, Oct 21, 2015 at 11:17:10AM -0700, Eric Rescorla wrote: > On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd wrote: > > > I like the idea. If the functionality is to be merged, perhaps harmonizing > > the names and contents of the messages (if possible)? > > > > Yes. My plan is to name it Hell

Re: [TLS] Controlling use of SHA-1

I think this is the right answer and parallels what we are doing with PSS. -Ekr On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely. Since we expressly forbid > the use of SH

[TLS] Controlling use of SHA-1

The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass indefinitely. Since we expressly forbid the use of SHA-1 for signing in TLS itself, we can just permit clients to include it in "signature_algorithms" and use that to determine whether SHA-1 is accept

Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt

> On 21 Oct 2015, at 9:03 PM, Short, Todd wrote: > > I agree with Ben here. This is very much application-layer (HTTPS) > functionality being pushed down into the security (TLS) layer. In fairness, if the TLS layer is blocking you, you don’t get to talk to the HTTP layer. So the captive porta

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

Not sure if I'm getting anything wrong, but doesn't this open a huge security hole? Scenario right now is that if I want to be secure on a webpage I type in its HTTPS URL (either directly or through a bookmark) and can be pretty much sure that as long as I don't click on external links that I'll s

Re: [TLS] HelloRetryRequest and stateless reject

On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd wrote: > I like the idea. If the functionality is to be merged, perhaps harmonizing > the names and contents of the messages (if possible)? > Yes. My plan is to name it HelloRetryRequest and get rid of HelloVerifyRequest. -Ekr > -Todd Short > // t

Re: [TLS] HelloRetryRequest and stateless reject

On Wed, Oct 21, 2015 at 11:07 AM, Benjamin Kaduk wrote: > On 10/21/2015 12:32 PM, Eric Rescorla wrote: > > Folks, > > Several of the remaining TLS 1.3 issues have to do with the > ClientHello/HelloRetryRequest interaction. To recap, if the > ClientHello does not contain a KeyShare with an accepta

Re: [TLS] HelloRetryRequest and stateless reject

I like the idea. If the functionality is to be merged, perhaps harmonizing the names and contents of the messages (if possible)? -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Oct 21, 2015, at 1:32 PM, Eric Rescorla

Re: [TLS] HelloRetryRequest and stateless reject

On 10/21/2015 12:32 PM, Eric Rescorla wrote: > Folks, > > Several of the remaining TLS 1.3 issues have to do with the > ClientHello/HelloRetryRequest interaction. To recap, if the > ClientHello does not contain a KeyShare with an acceptable group, the > server sends a HelloRetryRequest indicating t

Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt

I agree with Ben here. This is very much application-layer (HTTPS) functionality being pushed down into the security (TLS) layer. HTTP(S) already has a fully functional redirect mechanism, why does this functionality need to be pushed to a lower layer? All the cases described in the Introduction

[TLS] Proposal for client auth

Folks, At the Seattle interim, we decided to have a small ad hoc design team go and figure out how to harmonize the various forms of client authentication. I've posted a WIP version of the output of that work at: https://github.com/tlswg/tls13-spec/pull/316 The basic observation (due to

[TLS] HelloRetryRequest and stateless reject

Folks, Several of the remaining TLS 1.3 issues have to do with the ClientHello/HelloRetryRequest interaction. To recap, if the ClientHello does not contain a KeyShare with an acceptable group, the server sends a HelloRetryRequest indicating the correct group, and the client sends a ClientHello wit

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

On 10/21/15 8:13 AM, Benjamin Kaduk wrote: > I don't think that's quite the point I was trying to make. HTTPS is > HTTP layered on top of TLS, yes, but in order for there to be a > separation of layers, TLS should not include any data structures that > are only useful for the HTTPS case. This doc

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

On 10/20/2015 10:02 PM, Zhouqian (Cathy) wrote: > [Cathy]Yes, both web authentication and overdue use cases could be > considered as captive portals. And I have already sent an email to the > capport mailing list for their comments. I mentioned capport because it sounds like they are trying to so

Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support

On Wed, Oct 21, 2015 at 09:11:51AM +0300, Yoav Nir wrote: > LGTM. Can you push this to GitHub? > > > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara > > wrote: > > > > From: Ilari Liusvaara > > > > --- > > On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote: > >> Hi Ilari > >> > >>> - Is th