On Tue 2016-03-29 21:53:13 -0400, Sean Turner wrote:
> 1. The IANA registry rules for the TLS cipher suite registry [1] will be
> changed to specification required.
>
> 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”.
> Y and N have the following meaning:
>
> Cipher
Hi Sean
I also strongly support this. I’m just wondering how we plan to enforce the
"stable, publicly available, peer reviewed reference” part. As your examples
below show, the reference tends to be an I-D. That’s stable and publicly
available, but we have no idea if it’s peer reviewed or who
On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton wrote:
> We (Chrome) definitely want this (sending cookies in 0-RTT requests), and
> are doing this today with QUIC (which we can't wait to TLS 1.3-ify).
>
I went to RealWorldCrypto 2016 and saw the TLS track and all of the
analysis TLS 1.3 has r
On Wed, Mar 30, 2016 at 12:52:23PM +1100, Martin Thomson wrote:
> On 30 March 2016 at 12:49, Colm MacCárthaigh wrote:
> > But isn't that too late? If you have to wait for the client finished message
> > before you can even decrypt the 0RTT section; what's the benefit? it's not
> > "0RTT" any more.
在 16-3-30 下午12:17， "Peter Bowen" 写入:
>It doesn't seem to be clearly spelled out: is the "charging GW" a
>system that can read data passing between the client and server but
>cannot modify it? If so, do I have it right that you are trying to
>design an extension that allows the client to send a
Strongly support this.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi, Martin:
We are following the progress of that work. But in principle, any
extension to TLS should be done in this group, that is why we raised the
discussion in the TLS list. ^_^
Cheers
Dacheng
在 16-3-30 下午12:17， "Martin Thomson" 写入:
>On 30 March 2016 at 15:12, Dacheng Zhang
>wrote:
>> T
On 30 March 2016 at 15:12, Dacheng Zhang wrote:
> The charging GW will not authenticate the client, it only needs to be
> informed how the following traffics will be charged, in a trusted way.
We've seen this request before. It's not an easy question to answer.
In short, you want to make infor
It doesn't seem to be clearly spelled out: is the "charging GW" a
system that can read data passing between the client and server but
cannot modify it? If so, do I have it right that you are trying to
design an extension that allows the client to send a message that can
be observed but not tampere
The charging GW will not authenticate the client, it only needs to be
informed how the following traffics will be charged, in a trusted way.
That is why we will do this work. For secure reasons, we intend to use TLS
to secure the traffics to or from our APP. So, we need to provide such
information
Right. When we design this solution, we assume it will work with TLS1.3. The
TLS WG has stopped working on the extensions for TLS 1.2, right?
发件人: Eric Rescorla
日期: 2016年3月30日 星期三 上午11:59
至: Martin Thomson
抄送: dacheng de , tls
主题: Re: [TLS] 回复： A TLS extension transfering service indicatio
On 30 March 2016 at 15:04, Dacheng Zhang wrote:
> Dacheng：Let assume we trust the device. But the APP use a SNI to indicate
> the service that the APP intends to access. Because the SNI is static which
> may not be changed for months, it is easier for attackers who monitor the
> network to get the
Hi, Erk:
My reply inline please.
Cheers
Dacheng
发件人: Eric Rescorla
日期: 2016年3月30日 星期三 上午11:19
至: dacheng de
抄送: Eric Mill , Dave Garrett ,
tls
主题: Re: [TLS] 回复： A TLS extension transfering service indication
information
On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang
wrote:
> Hi, Ekr
On 30 March 2016 at 14:59, Eric Rescorla wrote:
> I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.2
> even
> with EMS because (even with the MAC) the SI extension is bound to the
> ClientHello
> which is replayable in 1.2 because it contains public information, with the
I meant "would work with TLS 1.3". I don't believe it will work with TLS
1.2 even
with EMS because (even with the MAC) the SI extension is bound to the
ClientHello
which is replayable in 1.2 because it contains public information, with the
only non-fixed information being the random. However in 1.3
On 30 March 2016 at 14:19, Eric Rescorla wrote:
> That wouldn't work with TLS 1.2 but would work with TLS 1.2.
I think that you meant that it would work with TLS 1.2 and extended
master secret, or TLS 1.3.
___
TLS mailing list
TLS@ietf.org
https://www.
On 30 March 2016 at 14:18, Colm MacCárthaigh wrote:
> though I'll note that it relies on basically a Mac-Then-Encrypt
> construction.
I don't think that the right term to apply here. This isn't record
protection. The MAC authenticates the handshake here, then we use
AEAD for record protection a
On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang
wrote:
> Hi, Ekr:
>
> Thanks for reviewing the draft and the comments. Please see my reply
> inline please.
>
> 发件人: Eric Rescorla
> 日期: 2016年3月30日 星期三 上午7:21
> 至: dacheng de
> 抄送: Eric Mill , Dave Garrett ,
> tls
> 主题: Re: [TLS] 回复： A TLS extensi
On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson
wrote:
> On 30 March 2016 at 12:49, Colm MacCárthaigh wrote:
> > But isn't that too late? If you have to wait for the client finished
> message
> > before you can even decrypt the 0RTT section; what's the benefit? it's
> not
> > "0RTT" any more.
>
Hi!
In Yokohama, we discussed changing the IANA registry assignment rules for
cipher suites to allow anyone with a stable, publicly available, peer reviewed
reference document to request and get a code point and to add an “IETF
Recommended” column to the registry. This change is motivated by t
On 30 March 2016 at 12:49, Colm MacCárthaigh wrote:
> But isn't that too late? If you have to wait for the client finished message
> before you can even decrypt the 0RTT section; what's the benefit? it's not
> "0RTT" any more.
There is a Finished message in the client's first flight. It's before
On Tue, Mar 29, 2016 at 6:25 PM, Martin Thomson
wrote:
> On 30 March 2016 at 11:30, Colm MacCárthaigh wrote:
> > * How is the elapsed time on the wire authenticated? can't an attacker
> > modify it and replay?
>
> It is authenticated by virtue of being part of the session transcript.
> It will b
On 30 March 2016 at 12:45, Kyle Nekritz wrote:
> The time since the client hello was sent/received can still be used if it is
> stored after opening the connection.
Only if we introduce an inconsistency by asking for different handling
in different circumstances. I agree that in many cases,
New
> Unfortunately, there is no client message that solicits the NewSessionTicket.
> The message can be sent spontaneously by a server at any time.
The time since the client hello was sent/received can still be used if it is
stored after opening the connection.
It's also important exactly where a
Hi, Ekr:
Thanks for reviewing the draft and the comments. Please see my reply inline
please.
发件人: Eric Rescorla
日期: 2016年3月30日 星期三 上午7:21
至: dacheng de
抄送: Eric Mill , Dave Garrett ,
tls
主题: Re: [TLS] 回复： A TLS extension transfering service indication
information
I have taken an initial
On 30 March 2016 at 05:00, David Benjamin wrote:
> On the server, OpenSSL already includes the version in the SSL_SESSION
> structure, and recent enough versions of it will not accept sessions at the
> wrong version
NSS too. This is the right thing, I think.
I have no objection to making this
On 30 March 2016 at 11:30, Colm MacCárthaigh wrote:
> * How is the elapsed time on the wire authenticated? can't an attacker
> modify it and replay?
It is authenticated by virtue of being part of the session transcript.
It will be authenticated by the Finished message included by the
client, by t
On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson
wrote:
> On 30 March 2016 at 06:53, Colm MacCárthaigh wrote:
> > It's likely I'm misunderstanding, but I'll ask to clear it up. Does this
> > proposal imply that a 0RTT section can only be sent within a very tight
> time
> > limit of when the serve
On 29 March 2016 at 22:32, Stephen Farrell wrote:
> In an offlist exchange with Martin, I suggested allowing
> finer granularity than 1s, e.g. 1ms.
I think that this is reasonable. This might allow for tighter
tolerance for drift, which means less replay opportunity.
On 30 March 2016 at 04:45,
I have taken an initial look at this document, but I find myself confused
about the security
model.
Specifically, you say that you can't use SNI because customers will lie and
insert
the SNI for service A in the ClientHello when going to service B. However,
I don't
see how this token stops that, s
Dear TLS Working Group,
this message relates mostly to (real-world) privacy, so I'd be particularly
grateful for comments from people concerned with that.
The TRON workshop [1] re-initiated a discussion about the handling of keys
among cryptography researchers involved with TLS. Although there
On Tue, Mar 29, 2016 at 3:29 AM, Martin Thomson
wrote:
> https://github.com/tlswg/tls13-spec/pull/437
>
> In short, have the client report the time since it received the
> configuration. Then have the server reject early data if the time
> doesn't match.
>
> I think that this is a relatively eas
On Tue, Mar 29, 2016 at 09:13:57AM -0700, Bill Cox wrote:
> As most people on this list know, stateful PSK 0-RTT can be more secure
> than any scheme possible with DHE 0-RTT, stateful or not.
I disagree with this.
Both PSK and DHE can with server-side state archive best possible
security (relat
On Tue, Mar 29, 2016 at 09:29:10PM +1100, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/pull/437
>
> In short, have the client report the time since it received the
> configuration. Then have the server reject early data if the time
> doesn't match.
>
> I think that this is a relat
On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote:
> On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote:
> >
> > There also seems to be (rougher) consensus not to support 0-RTT via DHE
> > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT
> mode
> > as PSK. The security
On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar wrote:
> Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that
> attacks on previous version of TLS can be used to attack new version of
> TLS.
>
> One thing that is not mandated by TLS 1.3 is separation of session tickets
> and
I think this will better account for the round trip delay if the elapsed_time
is defined on the client as the time since the request for the session ticket
(in other words, the time since the client hello was sent). That way both the
server computed time and the client reported time will include
On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote:
>
> There also seems to be (rougher) consensus not to support 0-RTT via DHE
> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode
> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT
> are almost identi
Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that
attacks on previous version of TLS can be used to attack new version of TLS.
One thing that is not mandated by TLS 1.3 is separation of session tickets and
session ids between TLS protocols. For example a client could use
On 29 Mar 2016, at 5:42 PM, Hubert Kario wrote:
> On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote:
>>> On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote:
>>>
>>> On Friday 25 March 2016 22:07:02 Yoav Nir wrote:
> On 25 Mar 2016, at 8:16 PM, Yuhong Bao
> wrote:
>
> I wonder if i
On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote:
> > On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote:
> >
> > On Friday 25 March 2016 22:07:02 Yoav Nir wrote:
> >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao
> >>> wrote:
> >>>
> >>> I wonder if it would be possible to publish
> >>> draft-ietf-tls-5
All,
To make sure we’ve got a clear way forward coming out of our BA sessions, we
need to make sure there’s consensus on a couple of outstanding issues. So...
There also seems to be (rougher) consensus not to support 0-RTT via DHE (i.e.,
semi-static DHE) in TLS 1.3 at this time leaving the on
All,
To make sure we’ve got a clear way forward coming out of our BA sessions, we
need to make sure there’s consensus on a couple of outstanding issues. So...
It seems that there is a clear consensus not to support 0-RTT client
authentication in TLS 1.3 at this time. If you think 0-RTT client
> On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote:
>
> On Friday 25 March 2016 22:07:02 Yoav Nir wrote:
>>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao
>>> wrote:
>>>
>>> I wonder if it would be possible to publish
>>> draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC
>>> 6101). It
Bill Cox writes:
>I spent 2 weeks last year tracking down a flaky bug that only occurs once in
>every 256 connection: the leading 0 byte was no longer being stripped in a
>code change I ported from OpenSSL master, and only Maria DB ran random tests
>enough to trigger this condition.
My self-test
On 29/03/16 11:29, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/pull/437
>
> In short, have the client report the time since it received the
> configuration. Then have the server reject early data if the time
> doesn't match.
>
> I think that this is a relatively easy change to
On Friday 25 March 2016 22:07:02 Yoav Nir wrote:
> > On 25 Mar 2016, at 8:16 PM, Yuhong Bao
> > wrote:
> >
> > I wonder if it would be possible to publish
> > draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC
> > 6101). It would start with
> > https://tools.ietf.org/html/draft-i
https://github.com/tlswg/tls13-spec/pull/437
In short, have the client report the time since it received the
configuration. Then have the server reject early data if the time
doesn't match.
I think that this is a relatively easy change to make. Now, your
exposure to replay is much less.
It's n
On 29 March 2016 at 19:21, Karthikeyan Bhargavan
wrote:
> Note that choosing the expiry/rollover period also determines the replay
> window,
I think that we can fix that one easily, as I suggested in an earlier
mail. I plan to open a PR that does that.
__
> We (Chrome) definitely want this (sending cookies in 0-RTT requests), and
> are doing this today with QUIC (which we can't wait to TLS 1.3-ify).
I see. So, it is quite likely that the most common usage of TLS 1.3 would send
sensitive data in 0-RTT.
It is unfortunate that the forward secrec
Hi,
Actually, we refer to the extension as a 'SNI' extension. In this extension,
SI(service indication) information is provided. In the next version, we will
use 'SI extension' to take place of 'SNI extension'. ^_^
Cheers
Dacheng___
TLS mailing list
TLS
51 matches
Mail list logo
