On Sat, Jul 25, 2015 at 03:00:54PM -0400, Dave Garrett wrote:
> On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote:
> > I would go further, and say that "prohibiting RC4" in any sense
> > that is more than prohibiting its use as the final outcome of a
> > handshake would be a rather coun
On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote:
> I would go further, and say that "prohibiting RC4" in any sense
> that is more than prohibiting its use as the final outcome of a
> handshake would be a rather counter-productive strategy.
>
> Servers and clients are strongly encourag
On Sat, Jul 25, 2015 at 07:01:42PM +0200, Martin Thomson wrote:
> On 25 July 2015 at 17:48, Salz, Rich wrote:
> > "we" meaning browsers. "we" not being everyone who will use TLS 1.3
> >
> > Ekr has pointed out a problem; if you connect with a protocol range and
> > proffer RC4, can we do anythi
On Sat, Jul 25, 2015 at 06:54:36AM +, Salz, Rich wrote:
> > What we've cannot yet turn off is RC4.
>
> Then do not use TLS 1.3
Actually, we can use TLS 1.3, just not with peers that only do RC4.
Provided the 1.3 servers don't do anything actively hostile and
terminate the handshake when they
On 25 July 2015 at 17:48, Salz, Rich wrote:
> "we" meaning browsers. "we" not being everyone who will use TLS 1.3
>
> Ekr has pointed out a problem; if you connect with a protocol range and
> proffer RC4, can we do anything about it except point out multiple times that
> 1.3 servers MUST NOT ac
> And the strategies vary. It might be that we don't need to worry about this,
> because we might have widely disabled RC4 by the time TLS
> 1.3 ships.
"we" meaning browsers. "we" not being everyone who will use TLS 1.3
Ekr has pointed out a problem; if you connect with a protocol range and pr
On 25 July 2015 at 16:13, Eric Rescorla wrote:
> The only question is whether it's legal to concurrently offer RC4 with TLS
> 1.3
> for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC
> even though TLS 1.3 does not support it.) I am trying to work through this
> myself, as the in
To be clear: TLS 1.3 does not support RC4.
The only question is whether it's legal to concurrently offer RC4 with TLS
1.3
for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC
even though TLS 1.3 does not support it.) I am trying to work through this
myself, as the interactions wit
> On 25/07/15 06:46, Viktor Dukhovni wrote:
>> I hope, that by ~2017, RC4 will no longer be required either, and
>> we'll be able to disable RC4 in Postfix at that time.
>
> Seems to me that should be a reasonable match for expecting to see
> TLS1.3 getting deployed in lots of parts of the mail i
(no hats and al that)
On 25/07/15 06:46, Viktor Dukhovni wrote:
> I hope, that by ~2017, RC4 will no longer be required either, and
> we'll be able to disable RC4 in Postfix at that time.
Seems to me that should be a reasonable match for expecting to see
TLS1.3 getting deployed in lots of parts
> What we've cannot yet turn off is RC4.
Then do not use TLS 1.3
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Fri, Jul 24, 2015 at 02:03:13PM -0400, Dave Garrett wrote:
> > and how a server can tell that the client is TLS1.3 only and not
> > TLS1.0-up-to-
> > TLS1.3?
>
> TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3
> only. A TLS 1.0-1.2 client, or at least one offering that,
On Thu, Jul 23, 2015 at 07:10:30PM +0200, Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> wrote:
>
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draf
> On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote:
>> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
>>> To be clear, the wording I have in the PR is not this broad. It only
>>> requires aborting if export ciphers were offered by a TLS 1.3+ client, not
>>> just any client.
>>
>> and ho
On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote:
> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> > To be clear, the wording I have in the PR is not this broad. It only
> > requires aborting if export ciphers were offered by a TLS 1.3+ client, not
> > just any client.
>
> and how a
On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote:
> > And I completely agree. FREAK and Logjam wouldn't happen at all if we
> > didn't drag with us stuff that was considered legacy 10 years ago.
> >
> > But stuff like "server MUST abort
On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote:
> And I completely agree. FREAK and Logjam wouldn't happen at all if we didn't
> drag with us stuff that was considered legacy 10 years ago.
>
> But stuff like "server MUST abort handshake if it sees export grade ciphers
> in
> Client Hel
On Thursday 23 July 2015 14:21:15 Dave Garrett wrote:
> On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> > >
> > wrote:
> > > A suggestion - could we remove mention of anything that
> > > is not a MUST or SHOULD ciphersuite from the
On Thu, Jul 23, 2015 at 06:06:04PM +0100, Stephen Farrell wrote:
>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restriction
On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> wrote:
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draft that
On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> > vast swaths of web servers are misconfigured; introducing a more complex
> > mechanism to server configuration when the existing situation is
> > incomprehensible to many administr
On Thursday 23 July 2015 18:06:04 Stephen Farrell wrote:
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restrictions section proh
On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
wrote:
>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restrictions section
; To: tls@ietf.org
> Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)
>
> On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
>
>> Right now, the restrictions section prohibits:
>> RC4, SSL2/3, & EXPORT/NULL entirely (via min
On 23/07/15 16:43, Dave Garrett wrote:
> We should just get more serious about banning old crap entirely to
> make dangerous misconfiguration impossible for TLS 1.3+
> implementations.
>
> Right now, the restrictions section prohibits: RC4, SSL2/3, &
> EXPORT/NULL entirely (via min bits) and has
On Thursday, July 23, 2015 12:00:34 pm Viktor Dukhovni wrote:
> On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
> > or abort with a fatal error.
>
> Who's going to police the Internet to remove all the legac
On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
So much for using NULL ciphers for client-server authentication
27 matches
Mail list logo
