It looks like we have rough consensus to accept this PR. We should make
sure we note the limitations that Karthink brought up for PSK and RSA,
https://mailarchive.ietf.org/arch/msg/tls/sZX9ursx4ePK2Zr-yflO2nUtiQY.
Procedurally, we should document the requirements for TLS 1.2 in a separate
draft to
No, you're right and I'm off : that value is in the past. I was treating it
as a 64-bit epoch value. Bad me for having a 2038-ready timestamp
interpreter.
On Mon, Nov 9, 2015 at 5:20 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 5:15 PM, Colm MacCárthaigh
> wrote:
>
>>
>> Would the values
Would the values chosen there have a calamitous impact on Mon, 24 Dec 2125
11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server would
put that value in. I know it's 110 years in the future, but would it be
better to choose a value that's in the past?
On Mon, Nov 9, 2015 at 3:52 PM,
On Monday, November 9, 2015 4:44 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema
> wrote:
>> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
>>> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
>>> wrote:
>...
Could you also add a reference to the do
On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema
wrote:
> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
>
> > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
> wrote:
> >
> >...
> >> Editorial: your proposed text says "...MUST set the first six bytes of
> its Random value
> >> to
On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
> wrote:
>
>...
>> Editorial: your proposed text says "...MUST set the first six bytes of its
>> Random value
>> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first
On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
wrote:
> On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote:
> > In an attempt to close the loop here, I've pushed a new PR version with
> a 64-bit sentinel with
> > the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone
> strongl
On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote:
> In an attempt to close the loop here, I've pushed a new PR version with a
> 64-bit sentinel with
> the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone strongly
> objects to this
> construction, please raise your hand now.
In an attempt to close the loop here, I've pushed a new PR version with a
64-bit sentinel with the final byte being 00 for TLS 1.2 and 01 for TLS
1.3. If anyone strongly objects to this construction, please raise your
hand now.
Otherwise, I plan to merge this on Wednesday.
https://github.com/tlsw
On 19 October 2015 at 08:08, Eric Rescorla wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel that
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
> the
> randomly generated portion always has a 2^{-n}
On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote:
> On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote:
>
>> Does the sentinel have to be the first N bytes?
>>
>> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
>> value and 28 random bytes.
>>
>> Rather than risk break
On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote:
> Does the sentinel have to be the first N bytes?
>
> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
> value and 28 random bytes.
>
> Rather than risk breaking backwards compatibility by changing the
> definition of the f
Does the sentinel have to be the first N bytes?
RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time value
and 28 random bytes.
Rather than risk breaking backwards compatibility by changing the definition of
the first 4 bytes, perhaps the sentinel can be moved to another locat
On Sat, Oct 17, 2015 at 03:20:08PM -0700, Eric Rescorla wrote:
> I don't feel strongly about this, but I don't see how what you suggest
> is any simpler than the version number encoding I proposed. Arguably,
> it's more complicated since you can't implement the sentinel check with
> memcmp().
Th
On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
>
> > > This argument is not complete. The false negative rate from TCP
> > > is not by itself sufficient to determine the observed error rate.
> > > One needs to combine that
On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
> > This argument is not complete. The false negative rate from TCP
> > is not by itself sufficient to determine the observed error rate.
> > One needs to combine that with the undetected error rate from
> > underlying network to obta
On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
>
> > > It also has a slightly better collision risk, though it's already down
> > > quite low
> >
> > Given that the TCP checksum has a false negative rate far higher than
> >
On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
> > It also has a slightly better collision risk, though it's already down
> > quite low
>
> Given that the TCP checksum has a false negative rate far higher than
> 2^{-56} and
> any TCP errors cause TLS handshake failures, this doesn
On Saturday, October 17, 2015 05:53:57 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
> wrote:
> > A 64-bit sentinel can be trivially checked as a 64-bit uint.
>
> And a 56-bit value can be trivially checked by masking off the last byte.
> Or, memcmp().
My point is that
On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> > wrote:
> >
> > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > > > The observation is still valuable i
On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> wrote:
>
> > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > > The observation is still valuable in the sense that prohibiting values
> > > > 1.3 would reduce the l
On Sat, Oct 17, 2015 at 02:16:49PM -0700, Eric Rescorla wrote:
> 3. (Optional) If you have a downgrade, parse the last byte to see the
> server's actual version.
> In any case, abort.
>
> What have I missed?
>From my perspective, there's not much benefit to knowing the actual
version, and an
On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > The observation is still valuable in the sense that prohibiting values
> > > 1.3 would reduce the likelihood of a false positive by some
> > miniscule amount. In other words
On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> The observation is still valuable in the sense that prohibiting values
> > 1.3 would reduce the likelihood of a false positive by some
> miniscule amount. In other words, I agree with ekr here, though we
> could cap the value to 1.3
On 17 October 2015 at 12:03, Eric Rescorla wrote:
>> Just a single
>> fixed patter signalling ">= 1.3" would then suffice.
>
>
> If you wanted to cover 1.2 -> 1.1, then you would want this.
The observation is still valuable in the sense that prohibiting values
> 1.3 would reduce the likelihood of
On Sat, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:
>
> > Trying to close the loop on this, I think people are generally in favor
> of
> > this
> > mechanism, so we just need a concrete construction.
> >
> > I propose we use an
On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:
> Trying to close the loop on this, I think people are generally in favor of
> this
> mechanism, so we just need a concrete construction.
>
> I propose we use an N bit field divided as follows
>
> - N - 8 bits of fixed sentinel.
> -
Trying to close the loop on this, I think people are generally in favor of
this
mechanism, so we just need a concrete construction.
I propose we use an N bit field divided as follows
- N - 8 bits of fixed sentinel.
- 8 bits of version number with the semantics being the highest TLS version
numb
Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2
implementations to signal each other about their preferred connection
parameters.
To make most use of the bytes provided, one could use the sentinel value to
indicate
support for an extension, which then carries a signed s
On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson
wrote:
> On 16 October 2015 at 13:39, Brian Smith wrote:
> > That would be especially true for an implementation that does False Start
> > for TLS 1.2.
>
> I don't see how false start plays into this. We could have clients
> reject false start if
On 16 October 2015 at 13:39, Brian Smith wrote:
> That would be especially true for an implementation that does False Start
> for TLS 1.2.
I don't see how false start plays into this. We could have clients
reject false start if they see this sentinel value. But don't we want
to just treat this
On Fri, Oct 16, 2015 at 10:04 AM, Martin Thomson
wrote:
> On 16 October 2015 at 12:22, Brian Smith wrote:
> > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile
> to
> > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> > something specific about TLS
On 16 October 2015 at 12:22, Brian Smith wrote:
> Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to
> protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> something specific about TLS 1.3 that makes the downgrade worse?
Given that we can't expect TLS
Karthikeyan Bhargavan wrote:
> The attack we’re protecting against is the following:
> [snip]
>
The key observation is that downgrade protection in TLS 1.2 (and below)
> relies on the Finished MAC, but the elements that go into computing this
> MAC (DH group, hash algorithm)
> are themselves neg
On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett
wrote:
> There is one problem with the current proposed sentinel value,
> 0x030403040304. It limits what can be done with future versions. It's not
> as simple as just making that use 0x030503050305, because we want 1.3
> clients to be able to recogni
> 1. Why would the server ever receive a TLS 1.2 or below ClientHello from a
> client that supports TLS 1.3? Why doesn't the already-standardized downgrade
> SCSV mechanism work for those cases?
The attack we’re protecting against is the following:
- a TLS 1.3 client sends a client hello and the
On Fri, Oct 9, 2015 at 2:23 AM, Eric Rescorla wrote:
> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
>
> https://github.com/tlswg/tls13-spec
> It's largely arbitrary, but the reasoning is as follows.
And so that we can put "TLS1.3" as the six bytes in UTF-8.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Friday, October 09, 2015 04:38:00 pm Viktor Dukhovni wrote:
> So even 2^{-48} is perhaps not quite low enough.
Going to a full 64-bit looks like a good idea to me. The loss of those 4 bytes
of entropy for old versions isn't likely to matter at all, though, please
correct me if someone thinks
On Fri, Oct 09, 2015 at 10:23:09PM +0200, Eric Rescorla wrote:
> It's largely arbitrary, but the reasoning is as follows. There are
> apparently some TLS 1.2 servers which randomly generate the entire server
> random (and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00
> would
> enc
It's largely arbitrary, but the reasoning is as follows. There are
apparently
some TLS 1.2 servers which randomly generate the entire server random
(and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 would
encourage more to do so). The chance of a false positive between such
a server
On Friday, October 09, 2015 12:49:02 pm Viktor Dukhovni wrote:
> I think this is "too clever" (a "hack" not a design) and offers
Every fix to an issue in this 20 year old protocol will be a hack.
> incomplete protection (does nothing to protect RSA key transport).
Better than none, for a very lo
On Fri, Oct 09, 2015 at 02:23:30PM +0200, Eric Rescorla wrote:
> Hi folks,
>
> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
>
> https://gi
On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd wrote:
>
>
> On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan <
> karthik.bharga...@gmail.com> wrote:
>
> - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will
> be dropped by
>TLS 1.3 clients, because of this proposal. This on
On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan
mailto:karthik.bharga...@gmail.com>> wrote:
- There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will be
dropped by
TLS 1.3 clients, because of this proposal. This only happens for servers
that do not
use the unix timest
On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
>
> > For reference, the version field in the TLS premaster secret is not
> checked by many servers, IIRC some of them have large market shares.
>
> That’s good to know. It would be tempting to recommend th
> For reference, the version field in the TLS premaster secret is not checked
> by many servers, IIRC some of them have large market shares.
That’s good to know. It would be tempting to recommend that TLS 1.3 servers
disable RSA (encryption) ciphersuites for all protocol versions, but I guess
On Fri, 09 Oct 2015 12:48:38 -, Karthikeyan Bhargavan
wrote:
- We note that RSA ciphersuites already provide a version downgrade
mitigation,
although it has itself caused many headaches due to bleichenbacher
attacks.
But if a server implements good side-channel resistance to
blei
A few more words on this proposal.
- The goal is to protect TLS 1.3 clients and servers from attacks on TLS 1.*
ciphersuites.
E.g. if a new attack on the MD5 | SHA1 concatenation in TLS 1.0 is
announced,
connections between TLS 1.3 clients and servers would still be protected.
Similarl
49 matches
Mail list logo
