> 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?
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
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
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
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
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)
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
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
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
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?
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
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
> 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.
> 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
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
> 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?
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,
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
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:
>
>
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
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
it ok
Sent from Outlook___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
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
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
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
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
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
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
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:
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
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
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
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
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
35 matches
Mail list logo