> I have to wonder if it’s worth it. In the last decade bandwidth has increased
> and prices for networking have gone down much faster than CPU speeds. 10
> years ago having 1 Mbps at home was the highest-end broadband you could get.
> Now you routinely get 100x that. CPU has increased, but now
Hi Simon, two technical typos:
The example cert in 8.2 has the wrong OID for the signature.
Cert has { 1 3 101 100 1 } [encoding 06 04 2B656401]
Text has { 1 3 101 101 } [encoding 06 03 2B6565] for id-EdDSASignature
OIDs use space-separated (not dot-separated) numbers in ASN.1.
Section 4:
Wro
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
> Sent: Wednesday, September 23, 2015 6:41 PM
> To: tls@ietf.org
> Subject: [TLS] Obscure ciphers in TLS 1.3
>
> https://tlswg.github.io/tls13-spec/#cipher-suites
> https://www.iana.org/assignments/tl
On 9/23/15 at 4:17 PM, noloa...@gmail.com (Jeffrey Walton) wrote:
IMHO, compression adds too many security vulnerabilities to a general
purpose secure communication protocol. I think TLS 1.3 is right in
eliminating it. It is too big a foot gun.
To play devil's advocate: if (1) compression incr
On Wednesday, September 23, 2015 07:40:13 pm Salz, Rich wrote:
> Do folks know that we did decide on the MTI list already, and that it's a
> matter of ekr updating the draft? (It was decided at a PREVIOUS interim, it
> just fell through the cracks.)
The MTI list and the larger list of what can/
Do folks know that we did decide on the MTI list already, and that it's a
matter of ekr updating the draft? (It was decided at a PREVIOUS interim, it
just fell through the cracks.)
And also, even if not, TLS 1.3 is only doing AEAD ciphers.
The registry isn't going to get purged, but all but tw
> On Sep 23, 2015, at 4:17 PM, Jeffrey Walton wrote:
>
>> IMHO, compression adds too many security vulnerabilities to a general
>> purpose secure communication protocol. I think TLS 1.3 is right in
>> eliminating it. It is too big a foot gun.
>
> To play devil's advocate: if (1) compression inc
Dave Garrett writes:
> Do either of these obscure ciphers actually get used enough to
> continue supporting in TLS 1.3+? (the AEAD versions, not the old
> suites that are no longer supported) If the answer is no, can we
> prohibit use of them in TLS 1.3+, or at least recommend against them?
Came
On 9/22/15 at 11:21 AM, basc...@gmail.com (Tony Arcieri) wrote:
On Tue, Sep 22, 2015 at 11:16 AM, Julien ÉLIE
wrote:
What for protocols that aren't subject to unsafe usage and that were
relying on the compression facility provided by TLS?
Unconditionally removing TLS compression leads to a re
On Wed, Sep 23, 2015 at 08:50:16AM -0700, Eric Rescorla wrote:
> On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
>
> > investigate: using the same construct for server/client sigs.
> >
> > Huh? Don't both currently use the same construct, except for the
> >
On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara
wrote:
> One thing to note: The time is 4 octets, and 32 bit time since unix
> epoch runs out a good bit faster than what I would like.
It's an unsigned value so it stretches until 2106 rather than the
standard epoch rollover at least.
>> investig
On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote:
> > I’ve gone ahead and posted the minutes/list of decisions to:
> >
> >
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-i
On Wed, Sep 23, 2015 at 01:43:29PM +, Dang, Quynh wrote:
> I am just curious why we need the content type here?
The "outer" content type is needed for backward compatiblity. The
"inner" content type is needed for stuff like handshake vs. alert or
appdata vs. alert.
-Ilari
_
I meant does *NOT* seem. We agree, sorry.
On Tue, Sep 22, 2015 at 10:55 PM, Tony Arcieri wrote:
> On Tue, Sep 22, 2015 at 8:32 PM, Colm MacCárthaigh
> wrote:
>
>> it doesn't seem too hard. My 2c: even if this were not the case,
>> optimizing NNTP in a backwards compatible way does seem like a
I am just curious why we need the content type here?
Quynh.
From: TLS on behalf of Dave Garrett
Sent: Tuesday, September 22, 2015 7:45 PM
To: Sean Turner
Cc: tls@ietf.org
Subject: Re: [TLS] '15 TLS Fall Interim Minutes
On Tuesday, September 22, 2015 0
On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote:
> I’ve gone ahead and posted the minutes/list of decisions to:
>
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
Minutes:
> ## Issue 223 - absolute or relative time
>
> Leave as-is because
Hi all,
I have pushed out a new version of the document describing EdDSA public
keys, signatures and certificates for PKIX. The change in -03 include
the addition of the prehash mode, test vectors generated by GnuTLS, and
a section recommending certain human readable names.
https://tools.ietf.or
Dear all,
In a recent work, we analyzed the ephemeral Diffie--Hellman-based
handshake protocol in two drafts of TLS 1.3 which were available at the
time of our research project in May: draft-ietf-tls-tls13-05 as well as
the variant proposal draft-ietf-tls-tls13-dh-based
(https://github.com/ekr/tls
18 matches
Mail list logo
