>Hmm. TLS has gotten too complex.
What makes you say that? Please be specific about what you think should be
taken out.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Yes to what Viktor proposed.
On 11/7/18, 11:27 PM, "TLS on behalf of Viktor Dukhovni" wrote:
> 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
Hiya,
On 08/11/2018 17:21, Hubert Kario wrote:
> what was the rationale for dropping the section about deprecating SHA-1 in
> TLS
> 1.2? I see nothing in minutes from IETF103.
I asked during the presentation if the WG wanted to
keep it or not, as it's clearly not quite the same
as the rest of
> On Nov 8, 2018, at 5:27 PM, Peter Gutmann wrote:
>
>> Always enforce peer certificate key usage (separation) for ECDSA. ECDSA keys
>> are more brittle when misused.
>
> Since ECDSA can only do signing, isn't this a bit redundant? In other words
> you can't really not enforce keyUsage for a
Blumenthal, Uri - 0553 - MITLL writes:
>Always enforce peer certificate key usage (separation) for ECDSA. ECDSA keys
>are more brittle when misused.
Since ECDSA can only do signing, isn't this a bit redundant? In other words
you can't really not enforce keyUsage for a signature-only algorithm.
On Thursday, November 8, 2018, Eric Rescorla wrote:
> It's also worth noting that in practice, many sites are served on
> multiple CDNs which do not share keying material.
>
>
Encrypting common knowledge is cargo cult fetishism for cryptography. The
files could be sent unencrypted, and
> On Nov 8, 2018, at 4:34 AM, Salz, Rich wrote:
>
> What makes you say that? Please be specific about what you think should be
> taken out.
One example area where the complexity is noticeably high:
* Certificate selection metadata specificity seems to far exceed
plausible diversity of
On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni wrote:
> On Thursday, November 8, 2018, Eric Rescorla wrote:
>
>> It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>>
> Encrypting common knowledge is cargo cult fetishism for
> On Nov 8, 2018, at 9:51 PM, Eric Rescorla wrote:
>
> I don't know what you consider "widespread", but presently both Chrome and
> Firefox support TLS 1.3, and our data shows that about 5% of Firefox
> connections use TLS 1.3. Chrome's numbers are similar and the numbers from
> the server
I think I have implied that ClientHello is unneccesary to an extent, it can
be replaced by a DNS TXT record.
I think I implied that self-signed certificates are acceptable given the
precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence
of DNS spoofing attacks against a CA?).
Hello,
пт, 9 нояб. 2018 г., 7:03 Ryan Carboni rya...@gmail.com:
> I think I have implied that ClientHello is unneccesary to an extent, it
> can be replaced by a DNS TXT record.
>
> I think I implied that self-signed certificates are acceptable given the
> precedent of Let’s Encrypt and the use
At IETF103, the WG considered the way forward for
draft-ietf-tls-dnssec-chain-extension. Based on the attempts at discussion on
the list and the sense in the room, the chairs believe that there is no longer
interest in continuing work on draft-ietf-tls-dnssec-chain-extension as a WG
document.
On Fri, Nov 9, 2018 at 2:20 AM Stephen Farrell
wrote:
> On 08/11/2018 17:21, Hubert Kario wrote:
> > what was the rationale for dropping the section about deprecating SHA-1 in
> > TLS
> > 1.2? I see nothing in minutes from IETF103.
>
> I asked during the presentation if the WG wanted to
> keep
Hi Ryan,
Thanks for your comments.
On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni wrote:
> Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe
> we should ask Google.
>
> The SSHFP DNS record exists. DNSSEC exists.
>
> This might be a radical proposal, but maybe the
On 8 Nov 2018, at 08:44, Ryan Carboni wrote:
>
> This might be a radical proposal, but maybe the certificate hash could be
> placed in a DNS TXT record.
This is a bad idea.
Overloading TXT records with special semantics rarely, if ever, has a happy
ending. For instance application software
> On Nov 9, 2018, at 00:21, Nico Williams wrote:
>
> On Thu, Nov 08, 2018 at 11:49:45AM -0500, Paul Wouters wrote:
>> I wanted to thank Ben for the outreach he did in the last six months on
>> the tls dnssec chain extension. It has been a difficult issue and I do
>> wish the outcome was
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 : TLS 1.3 Extension for Certificate-based
Authentication with an External Pre-Shared Key
Author :
> On Nov 9, 2018, at 1:19 AM, Peter Gutmann wrote:
>
>> Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be
>> used for encryption with ECIES.
>
> Sure, in theory, but in practice I've never seen an (EC)DH cert used in TLS
> (despite actively looking for one,
Nor have
Viktor Dukhovni writes:
>Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be
>used for encryption with ECIES.
Sure, in theory, but in practice I've never seen an (EC)DH cert used in TLS
(despite actively looking for one, since it'd be a collectors item for the
cert
I wanted to thank Ben for the outreach he did in the last six months on
the tls dnssec chain extension. It has been a difficult issue and I do
wish the outcome was different. But during this time Ben put a lot of
effort in trying to get the issues clarified and resolved both on the
list of
On Thursday, 8 November 2018 06:28:31 CET internet-dra...@ietf.org wrote:
> 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
>
On Thu, Nov 08, 2018 at 11:49:45AM -0500, Paul Wouters wrote:
> I wanted to thank Ben for the outreach he did in the last six months on
> the tls dnssec chain extension. It has been a difficult issue and I do
> wish the outcome was different. But during this time Ben put a lot of
> effort in
22 matches
Mail list logo
