> 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,
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
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
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
> 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
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
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 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
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 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
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 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 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
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
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
> 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
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.
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 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
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
>
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
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
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
>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
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
25 matches
Mail list logo
