Geoffrey Keating wrote:
> Viktor Dukhovni writes:
>>
>> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer
>> certificate that *only* lists:
>>
>> X509v3 Key Usage:
>> Key Encipherment, Data Encipherment
>
> Yes, because in DHE-RSA, the RSA key is used
On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote:
> There is *ZERO* security problem associated with TLS client allowing
> a TLS server to do this, but it makes it harder to catch defective
> CA software and bogus CA issuing practices when clients do not complain
> here
The interoperabi
On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni
wrote:
> [ Quoted text slightly reordered to put the RSA issue first, as that's
> the main thing I'm trying to get clarity on, and enabling keyUsage
> enforcement is causing some interoperability issues now... ]
>
> > On Nov 5, 2018, at 11:11 PM,
Viktor Dukhovni writes:
> [ Quoted text slightly reordered to put the RSA issue first, as that's
> the main thing I'm trying to get clarity on, and enabling keyUsage
> enforcement is causing some interoperability issues now... ]
>
> > On Nov 5, 2018, at 11:11 PM, Geoffrey Keating wrote:
> >
Adopt it. It's a small, useful feature.
On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote:
>
> At TLS@IETF103, there was consensus in the room to adopt
> draft-wood-tls-ticketrequests. This message is to confirm that consensus.
> If you do not support adoption of draft-wood-tls-ticketrequests
As a co-author, I do support adoption, as this will help optimize client
connection racing.
Tommy
> On Nov 8, 2018, at 8:07 AM, Martin Thomson wrote:
>
> Adopt it. It's a small, useful feature.
> On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote:
>>
>> At TLS@IETF103, there was consensus in
I support adoption and I am sure OpenSSL will implement, or I will do it and
make a PR.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi everyone,
Over in the Babel working group we have a draft about securing Babel with
DTLS:
https://tools.ietf.org/html/draft-ietf-babel-dtls-01
It's 5 pages long, could any TLS experts please give it a quick read and
let us know if we're using DTLS correctly?
Also, should the document contain
Viktor Dukhovni writes:
>On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote:
>> There is *ZERO* security problem associated with TLS client allowing
>> a TLS server to do this, but it makes it harder to catch defective
>> CA software and bogus CA issuing practices when clients do not comp
I support the adoption as well, we need it for lurk.
Yours,
Daniel
On Wed, Nov 7, 2018 at 8:31 PM Salz, Rich wrote:
> I support adoption and I am sure OpenSSL will implement, or I will do it
> and make a PR.
>
> ___
> TLS mailing list
> TLS@ietf.org
>
Peter,
I think your code did exactly right. The standard requires honoring KeyUsage..
Maybe if more implementations were diligent with this, the cert zoo we're
observing would've been less wild...
Regards,
Uri
Sent from my iPhone
> On Nov 7, 2018, at 21:21, Peter Gutmann wrote:
>
> Viktor
> On Nov 7, 2018, at 6:07 PM, Geoffrey Keating wrote:
>
> n general, though, what you're asking is "The CA signing this key has
> instructed that I do not accept signatures made with it. Is it OK to
> accept signatures made with it?" It's really hard to see how the
> answer to that could general
Hi David,
A few quick notes below.
Cheers
The 11/08/2018 09:14, David Schinazi wrote:
> Hi everyone,
>
> Over in the Babel working group we have a draft about securing Babel with
> DTLS:
> https://tools.ietf.org/html/draft-ietf-babel-dtls-01
>
> It's 5 pages long, could any TLS experts please
I took a quick look at the document and I don't know Babel.
I see that you have two different proposals for securing Babel messages, namely
* DTLS, and
* a custom format offering integrity protection only.
You correctly note in the document that DTLS offers more features. It is an aut
+1 to adoption. I found myself unsure of how many tickets to send in the new Go
implementation, which is notoriously averse to configuration knobs, and would
love to have the client pick.
2018-11-07 14:47 GMT+0700 Sean Turner :
> At TLS@IETF103, there was consensus in the room to adopt draft-woo
I support adoption, this seems straightforward and is a good solution to a real
world problem I’ve got.
Thanks,
Eric
> On Nov 8, 2018, at 9:44 AM, Daniel Migault
> wrote:
>
> I support the adoption as well, we need it for lurk.
> Yours,
> Daniel
>
>> On Wed, Nov 7, 2018 at 8:31 PM Salz, R
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 : Deprecating TLSv1.0 and TLSv1.1
Authors : Kathleen Moriarty
Stephen Farrel
Hiya,
This version attempts to make the few changes discussed
at the meeting on Monday. I wrote a script that gave me
a list of 76(!) RFCs this might need to update, and may
of course have mucked that up, so if anyone has a chance
to check if (some of) those make sense, that'd be great.
Ta,
S.
18 matches
Mail list logo
