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 certificate hash could be
placed in a DNS TXT record. In another DNS TXT record, a list of supported
protoco
>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
On Wednesday, November 7, 2018, 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 WG item
> please say so by 2359UTC on 30
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 i
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 offli
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 trying
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
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 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 si
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?).
I
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 certifi
> 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 cho
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 wo
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 protected
> 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 differe
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 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 cr
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 of
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 it
> 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 sid
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 : Ru
Minutes from both meetings this week are now posted:
https://datatracker.ietf.org/doc/minutes-103-tls/
Please send any updates or corrections to the list. And thanks to Rich,
Mike, and Matt for lending a hand!
Best,
Chris
___
TLS mailing list
TLS@ie
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 collec
> 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 I,
25 matches
Mail list logo
