Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Salz, Rich
> If we (okay, not "we", library implementors) require explicit application opt- > in to TLS 1.3, the adoption rate is probably not going to be very good. So, > yes, > I think applications should start using TLS 1.3 without any changes. And what about 0RTT? Removed support for some crypto?

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Martin Thomson
On 22 October 2015 at 09:19, Benjamin Kaduk wrote: > > % a certificate that specifies a trust anchor MAY be omitted from the chain > > The client cannot decide that the signature on the root cert the server > sent is bad, if the server does not send the root cert. Yes, that

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Andrei Popov
To be clear, I'm in favor of introducing server-side NamedGroups in 1.3. I've no interest in making this change in any earlier protocol versions. Cheers, Andrei From: Eric Rescorla Sent: 10/22/2015 10:40 AM To: m...@sap.com Cc: Andrei Popov; tls@ietf.org

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Benjamin Kaduk
On 10/22/2015 01:00 PM, Salz, Rich wrote: >> That is, the library update can be transparent to the end-user, who will >> continue to expect normal functionality and expect everything to work. > Should all applications suddenly start using TLS 1.3 without any changes? > Really? Or should what

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Russ Housley
I am also in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not include SHA-1. Russ 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

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

2015-10-22 Thread Roland Zink
Am 21.10.2015 um 20:22 schrieb Hanno Böck: Not sure if I'm getting anything wrong, but doesn't this open a huge security hole? Yes I think so. Mitm may redirect you. 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)

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Rob Stradling
On 22/10/15 00:52, Dave Garrett wrote: 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, IINM this also changes the fallback for servers that choose to include a PKIX trust

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Martin Rex
Andrei Popov wrote: > > Then my argument would be: why send extra bytes in each ServerHello > when TLS client auth is not used most of the time? In this case, > CertificateRequest seems to be a better place. I'm perfectly OK with the server _not_ sending/including a TLS extension "Supported

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Eric Rescorla
On Thu, Oct 22, 2015 at 11:00 AM, Salz, Rich wrote: > > That is, the library update can be transparent to the end-user, who will > > continue to expect normal functionality and expect everything to work. > > Should all applications suddenly start using TLS 1.3 without any

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Watson Ladd
On Oct 22, 2015 2:00 PM, "Salz, Rich" wrote: > > > That is, the library update can be transparent to the end-user, who will > > continue to expect normal functionality and expect everything to work. > > Should all applications suddenly start using TLS 1.3 without any changes?

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Ilari Liusvaara
On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote: > On 10/22/2015 01:00 PM, Salz, Rich wrote: > >> That is, the library update can be transparent to the end-user, who will > >> continue to expect normal functionality and expect everything to work. > > Should all applications suddenly

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Martin Thomson
On 22 October 2015 at 10:11, Andrei Popov wrote: > Then my argument would be: why send extra bytes in each ServerHello when TLS > client auth is not used most of the time? In this case, CertificateRequest > seems to be a better place. I think that this is the best

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Salz, Rich
> Maybe it would help if Victor could describe the situation in which he thinks > that it would be appropriate to send a certificate that is signed by MD5. Or where an application upgrades to a new library and expects EVERYTHING to work exactly as it used to, with no changes.

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Salz, Rich
> Most applications want a simple API that hides all the complexities of TLS. > If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't > cause problems for those apps which said "you take care of it". As someone with a long history of building, influencing, and using

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Eric Rescorla
On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex wrote: > Andrei Popov wrote: > > > > Then my argument would be: why send extra bytes in each ServerHello > > when TLS client auth is not used most of the time? In this case, > > CertificateRequest seems to be a better place. > > I'm

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Salz, Rich
> That is, the library update can be transparent to the end-user, who will > continue to expect normal functionality and expect everything to work. Should all applications suddenly start using TLS 1.3 without any changes? Really? Or should what *they used to do* just work as it was? If that?

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Viktor Dukhovni
On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote: > > % a certificate that specifies a trust anchor MAY be omitted from the chain > > > > The client cannot decide that the signature on the root cert the server > > sent is bad, if the server does not send the root cert. > > Yes,

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Watson Ladd
On Oct 22, 2015 2:20 PM, "Salz, Rich" wrote: > > > If we (okay, not "we", library implementors) require explicit application opt- > > in to TLS 1.3, the adoption rate is probably not going to be very good. So, yes, > > I think applications should start using TLS 1.3 without any

Re: [TLS] Proposal for client auth

2015-10-22 Thread Ilari Liusvaara
On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote: > 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: > >

Re: [TLS] Proposal for client auth

2015-10-22 Thread Eric Rescorla
On Thu, Oct 22, 2015 at 10:26 AM, Ilari Liusvaara wrote: > On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote: > > 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

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Bill Frantz
On 10/23/15 at 2:02 PM, ynir.i...@gmail.com (Yoav Nir) wrote: That is true only if your application’s client component and server component are using the same library. That is not guaranteed in a protocol. Specifically that is not the case with the web. There are some version intolerant

[TLS] re

2015-10-22 Thread Sultana Parveen
it ok Sent from Outlook___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Martin Thomson
On 22 October 2015 at 11:17, Watson Ladd wrote: > Ideally, yes. Applications never cared about what was happening, but wanted > a "secure this channel" magic call. I think that this is conditionally true. If you are using TLS 1.2 with reasonably modern practices, then

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Dave Garrett
On Thursday, October 22, 2015 09:29:22 am Eric Rescorla wrote: > From an implementation perspective, I wouldn't be surprised if client > implementations choked on the server sending this. [...] Hence my side-note that we should be explicit that it's for TLS 1.3+ (even if it's implicit

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Dave Garrett
On Thursday, October 22, 2015 02:18:30 pm Andrei Popov wrote: > What if we just made an explicit exception for root cert hash algorithms and > not constrained them by the client's alg list? +1 ___ TLS mailing list TLS@ietf.org

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Viktor Dukhovni
On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote: > IINM this also changes the fallback for servers that choose to include a > PKIX trust anchor certificate in the Server Certificate message. The signatures of trust-anchor (i.e. self-signed) certificates MUST NOT be constrained by

Re: [TLS] Version in record MAC

2015-10-22 Thread Eric Rescorla
Thanks for the quick response, David. I now agree with Martin and Adam that we should remove this. Chairs, I haven't seen any objections any reason I shouldn't make this change? -Ekr On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) wrote: > > > *From:* Eric Rescorla

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Eric Rescorla
On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex wrote: > Eric Rescorla wrote: > > 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

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Martin Rex
Eric Rescorla wrote: > 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

Re: [TLS] Version in record MAC

2015-10-22 Thread David McGrew (mcgrew)
From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Thursday, October 22, 2015 9:33 AM To: Adam Langley Cc: Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew) Subject: Re: [TLS] Version in record MAC I'm mostly convinced by this text in RFC 5116:

Re: [TLS] Version in record MAC

2015-10-22 Thread Eric Rescorla
I'm mostly convinced by this text in RFC 5116: http://tools.ietf.org/html/rfc5116#section-2.1 Because the authenticated decryption process detects incorrect nonce values, no security failure will result if a nonce is incorrectly reconstructed and fed into an authenticated decryption

Re: [TLS] Controlling use of SHA-1

2015-10-22 Thread Geoffrey Keating
Viktor Dukhovni writes: > On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote: > > > IINM this also changes the fallback for servers that choose to include a > > PKIX trust anchor certificate in the Server Certificate message. > > The signatures of

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Andrei Popov
Would the server-side “supported elliptic curves” be used for anything other than guiding client cert selection? Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Thursday, October 22, 2015 6:29 AM To: m...@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Allow

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Eric Rescorla
Not that I am aware of. On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov wrote: > Would the server-side “supported elliptic curves” be used for anything > other than guiding client cert selection? > > > > Cheers, > > > > Andrei > > > > *From:* TLS

Re: [TLS] Allow NamedGroups from the server?

2015-10-22 Thread Andrei Popov
Then my argument would be: why send extra bytes in each ServerHello when TLS client auth is not used most of the time? In this case, CertificateRequest seems to be a better place. From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Thursday, October 22, 2015 10:08 AM To: Andrei Popov