Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Yoav Nir]

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 the author’s peers 
are.

One other thing, in some of the links you pasted below you give a specific 
draft version (like 
https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while for the 
others you give the generic version (like 
https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/). The former is stable but 
the latter is not. Are the authors free to keep modifying the specification 
after getting the code point?

Yoav

> On 30 Mar 2016, at 4:53 AM, Sean Turner  wrote:
> 
> 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 the 
> large # of requests received for code points [0], the need to alter the 
> incorrect perception that getting a code point somehow legitimizes the 
> suite/algorithm, and to help implementers out.  We need to determine whether 
> we have consensus on this plan, which follows:
> 
> 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 suites marked with a “Y” the IETF has consensus on
> and are reasonably expected to be supported by widely
> used implementations such as open-source libraries.  The
> IETF takes no position on the cipher suites marked with an
> “N”.  Not IETF recommended does not necessarily (but can)
> mean that the ciphers are not cryptographically sound (i.e.,
> are bad).  Cipher suites can be recategorized from N to Y
> (e.g., Curve448) and vice versa.
> 
> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that 
> matches the above so that the same information is available to those who 
> don’t read the IANA considerations section of the RFC.
> 
> Please indicate whether or not you could support this plan.
> 
> Thanks,
> 
> J
> 
> [0] In the last year, the chairs have received requests for:
> 
> PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
> AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
> Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
> dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
> NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
> JPAKE: not sure they got around to publishing a draft.
> 
> [1] 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

[Tony Arcieri]

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 received, and while it wasn't TRON, I can sympathize
with why you might want TLS 1.3, namely the extensive analysis it is
receiving as an up and coming cryptographic standard which is a clear
choice for academic researchers to focus on.

That said, I really don't understand Google's excitement to switch from
QUIC's crypto to TLS 1.3. QUIC crypto seems like a much simpler and cleaner
protocol which fulfills many of the same goals as TLS, and while it hasn't
received as much scrutiny as TLS 1.3, it seems like it doesn't need as much
by design due to its relative simplicity.

I also understand Facebook is adding QUIC-crypto-over-TCP support to
proxygen (there was also a talk at RWC2016) for use in their mobile apps as
a stopgap for doing 0-RTT until such a time as 0-RTT ships in TLS 1.3.

Can you speak to specific reasons why the Chrome team "can't wait to TLS
1.3-ify" over QUIC, specifically reasons different from the ones I have
already highlighted above?

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Ilari Liusvaara]

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.
> 
> There is a Finished message in the client's first flight.  It's before
> the early data.

Only if using 0-RTT auth, which seems is going to be removed (yay).

However, one still can't tamper with timestamp in ClientHello: The
ClientHello affects the 0-RTT encryption keys and 0-RTT decrypt failure
(as opposed to not being able to derive 0-RTT keys) is a fatal error
(no fallback).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Dacheng Zhang]

在 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 message that can
>be observed but not tampered?
We translate that term from Chinese directly, and sorry for the confusion
caused. You are right, we trying to do this work in a standard way.

There could be hundreds of millions APP in use. The solution should be
scalable and light weight.

Cheers

Dacheng


>
>On Tue, Mar 29, 2016 at 9:12 PM, 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.
>> 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 in some way to the charging GW of ISP.
>>
>> 在 16-3-30 下午12:06， "Martin Thomson"  写入:
>>
>>>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 SNI and use it to gain benefit. We need a securer
 solution. As I have mentioned in my previous email, this solution will
make
 such attacks more difficult. By the way, SNI is not designed for this
 purpose, we need to do some additional work to address this issue,
right?
>>>
>>>
>>>What is wrong with client authentication?
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Salz, Rich]

Strongly support this.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[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 message that can
be observed but not tampered?

On Tue, Mar 29, 2016 at 9:12 PM, 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.
> 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 in some way to the charging GW of ISP.
>
> 在 16-3-30 下午12:06， "Martin Thomson"  写入:
>
>>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 SNI and use it to gain benefit. We need a securer
>>> solution. As I have mentioned in my previous email, this solution will
>>>make
>>> such attacks more difficult. By the way, SNI is not designed for this
>>> purpose, we need to do some additional work to address this issue,
>>>right?
>>
>>
>>What is wrong with client authentication?
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Martin Thomson]

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 SNI and use it to gain benefit. We need a securer
> solution. As I have mentioned in my previous email, this solution will make
> such attacks more difficult. By the way, SNI is not designed for this
> purpose, we need to do some additional work to address this issue, right?


What is wrong with client authentication?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Martin Thomson]

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
> only non-fixed information being the random. However in 1.3 it contains the
> DH
> key share, which the attacker doesn't know the corresponding private value
> for.


Right.  Score one for TLS 1.3.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Eric Rescorla]

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 it contains the
DH
key share, which the attacker doesn't know the corresponding private value
for.

-Ekr


On Tue, Mar 29, 2016 at 8:53 PM, Martin Thomson 
wrote:

> 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.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Martin Thomson]

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 afterwards.  Same as TLS has always done.
It's basic SIGMA.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Colm MacCárthaigh]

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.
>
> There is a Finished message in the client's first flight.  It's before
> the early data.
>
> https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2


Sorry, I thought that Finished message disappeared due to concerns over not
including any server data. That makes more sense of it; though I'll note
that it relies on basically a Mac-Then-Encrypt construction.



-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] call for consensus: changes to IANA registry rules for cipher suites

[Sean Turner]

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 the large # 
of requests received for code points [0], the need to alter the incorrect 
perception that getting a code point somehow legitimizes the suite/algorithm, 
and to help implementers out.  We need to determine whether we have consensus 
on this plan, which follows:

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 suites marked with a “Y” the IETF has consensus on
 and are reasonably expected to be supported by widely
 used implementations such as open-source libraries.  The
 IETF takes no position on the cipher suites marked with an
 “N”.  Not IETF recommended does not necessarily (but can)
 mean that the ciphers are not cryptographically sound (i.e.,
 are bad).  Cipher suites can be recategorized from N to Y
 (e.g., Curve448) and vice versa.

3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that matches 
the above so that the same information is available to those who don’t read the 
IANA considerations section of the RFC.

Please indicate whether or not you could support this plan.

Thanks,

J

[0] In the last year, the chairs have received requests for:

PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/
AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt
Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
NTRU:  http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt
JPAKE: not sure they got around to publishing a draft.

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Martin Thomson]

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
the early data.

https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Colm MacCárthaigh]

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 be authenticated by the Finished message included by the
> client, by the key derivation, and ultimately by the remainder of the
> 1RTT handshake.
>

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.

>
> > * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I
> > guess) ?
>
> No.  The server records the time that it generates the ticket.  Then
> that ticket travels to the client (1/2 RTT).  At that point the
> counter starts.  Then, on resumption, the client stops the clock and
> sends the message to the server (1/2 RTT).
>

Makes sense!


-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Martin Thomson]

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,
NewSessionTicket is generated in response to something in the client's
first flight, but that's not a guarantee.

> It's also important exactly where and when the server checks the timestamp. 
> If the timestamp is solely checked upon receipt of the client hello, an 
> attacker can slowly trickle replayed 0-RTT data to the server, which somewhat 
> defeats the point of a very narrow replay window (with a 1 second window, the 
> connection must be opened with 1 second, but the application data could 
> actually get delivered minutes later).

If you want to handle the pathological cases, feel free to propose mitigation.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Dacheng Zhang]

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 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, since all it represents is a bare assertion
of where
you are going that is authenticated with a MAC shared between the client,
the
ICP, and the ISP. What stops the client from doing the same thing, i.e.,
injecting
the token for service A into a connection destined for service B? B can just
ignore
the SI token, right?

Dacheng： This is a very good point. How to secure the APPs on the client
device (e.g., How to secure client and prevent the message sent out from an
APP provided by ICP A from being intercepted by an APP provided by ICP B
installed on the same mobile)  is a hot topic. Lots of people are working
hard to address this issue. For instance, TEE is an attempt of protecting
the security of APPS on a mobile. In a TEE, APPs action are controlled and
secure channels are provided to distributed keys. So, in our solution, we
did not consider the case where the execution environment of APPs is not
secure. We assume if an attacker or a malicious has compromise a mobile, it
could cause more serious damages.


Second if the tokens are client specific, what stops an attacker from
copying my
token and then replaying it in a separate connection, thus potentially
causing
the system to charge me or at least to use my rates for the attacker?

Dacheng: You are right. Since we use timestamps, there could a window for an
attacker to perform attacks by replaying or reusing the token. But we have
narrow down the attack window and mitigate the problem. But Thank you for
this comment. I got an idea. If the HMAC can cover the whole client hello
message, it will be harder for the attacker to reuse the token.Thoughts?

In short, this document needs a threat model (see RFC 3552) and an analysis
of why this solution meets that threat model.

Dacheng: Agree! Will do that in the next version. In addition, we will be
very happy if you have no problem with the requirement. We found this issue
when we tried to widely use TLS to secure the communications between our
APPs and our services. If there could be any better idea or solution, we
will be very happy to support it.

Finally, why am I seeing what appears to be a MAC algorithm definition in
Section
2.1. Is there a reason you can't just use/cite HMAC?

Dacheng: I reuse this content from my previous drafts. If people don’t like
it, we could remove it. ^_^

Thanks a lot for your review, and look forward to further discussions on
this topic. ^_^

Cheers

Dacheng

-Ekr








On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang
 wrote:
> 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
>> --
>> 发件人：Dave Garrett 
>> 发送时间：2016年3月29日(星期二) 14:52
>> 收件人：Eric Mill 
>> 抄　送：tls ，张大成(淡久) 
>> 主　题：Re: [TLS] A TLS extension transfering service indication information
>> 
>> On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote:
>>> > It looks like the abbreviation this draft uses is just "SI". It uses SNI
>>> at
>>> > the top a few times to refer to Server Name Indication (which it typos as
>>> > "service" name extension).
>>> > 
>>> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett 
>>> wrote:
 > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote:
 > > 
 
https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/
 > >
 > > You really should not use SNI as your abbreviation, as it will just be
 > > frequently confused with the server_name extension which is already the
 > > dominant use of those initials in TLS.
>> 
>> You're correct; my mistake. I didn't notice the typo and reading a spec draft
>> whilst tired is not always the best of ideas. ;)
>> 
>> CCing back to list and thread starter to make sure my correction is OTR for
>> the list.
>> 
>> Fixing that typo in the draft would help to avoid future misreadings.
>> Sticking in a direct reference to RFC6066 on first mention of SNI could add
>> another level of clarification, if desired.
>> 
>> Thanks for quickly correcting me.
>> 
>> 

Re: [TLS] Tickets and cross protocol attacks

[Martin Thomson]

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 a requirement in the spec.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing the replay window

[Colm MacCárthaigh]

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 server provided a resumption ticket/configuration?
>
> No.  If we accept Stephen's suggestion and go to milliseconds (I will
> do that), then the maximum age of a ticket is just over 7 weeks.  Much
> longer than the time we allow a resumption ticket to live.
>

i did mis-understand so; I read your PR as suggesting that the server
should impose a small limit on the elapsed time itself.

But now I think what you're saying is this; the server should check that
the same amount of time (modulo an RTT) has elapsed on both the client and
the server. A few other questions;

* How is the elapsed time on the wire authenticated? can't an attacker
modify it and replay?
* Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I
guess) ?
* Clock drift; especially on clients, seems like a real problem here - how
tight would realistic tolerances be?

-
 Colm



-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 回复： A TLS extension transfering service indication information

[Eric Rescorla]

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, since all it represents is a bare assertion
of where
you are going that is authenticated with a MAC shared between the client,
the
ICP, and the ISP. What stops the client from doing the same thing, i.e.,
injecting
the token for service A into a connection destined for service B? B can
just ignore
the SI token, right?

Second if the tokens are client specific, what stops an attacker from
copying my
token and then replaying it in a separate connection, thus potentially
causing
the system to charge me or at least to use my rates for the attacker?

In short, this document needs a threat model (see RFC 3552) and an analysis
of why this solution meets that threat model.

Finally, why am I seeing what appears to be a MAC algorithm definition in
Section
2.1. Is there a reason you can't just use/cite HMAC?

-Ekr








On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang  wrote:

> 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
>
> --
> 发件人：Dave Garrett 
> 发送时间：2016年3月29日(星期二) 14:52
> 收件人：Eric Mill 
> 抄 送：tls ，张大成(淡久) 
> 主 题：Re: [TLS] A TLS extension transfering service indication information
>
> On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote:
>
> > It looks like the abbreviation this draft uses is just "SI". It uses SNI at
> > the top a few times to refer to Server Name Indication (which it typos as
> > "service" name extension).
> >
> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett  > wrote:
> > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote:
> > >
> https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/
> > >
> > > You really should not use SNI as your abbreviation, as it will just be
> > > frequently confused with the server_name extension which is already the
> > > dominant use of those initials in TLS.
>
>
> You're correct; my mistake. I didn't notice the typo and reading a spec draft 
> whilst tired is not always the best of ideas. ;)
>
>
> CCing back to list and thread starter to make sure my correction is OTR for 
> the list.
>
>
> Fixing that typo in the draft would help to avoid future misreadings. 
> Sticking in a direct reference to RFC6066 on first mention of SNI could add 
> another level of clarification, if desired.
>
> Thanks for quickly correcting me.
>
>
> Dave
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Key separation and privacy

[Björn Tackmann]

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 is no 
unanimous opinion on this matter, I think it is fair to say that the majority 
of cryptographers support the principle of key separation, that is, using each 
cryptographic key derived within the protocol (only) for its specific purpose. 
(This simplifies the analysis significantly, but it also helps to avoid 
unintended interactions between different protocol parts and to keep things 
nice and modular.) We are particularly concerned with the traffic keys used for 
handshake and for application data.

The current TLS 1.3 draft is somewhat inconsistent here. While the ordinary 
handshake messages are encrypted under a handshake traffic key HTK, "late" 
handshake messages (NewSessionTicket and post-handshake client authentication) 
are intermixed with application data messages and encrypted under the 
application traffic key ATK. Encrypting late handshake messages with HTK 
instead of ATK would cause the problem that the receiver must know which key to 
use for decrypting a received message; the somewhat most straightforward way 
would be to make the messages clearly distinguishable, another way would be to 
do trial decryption for each incoming message with ATK and, in case of failure, 
decrypt with HTK. This key HTK could be the very same key as the one used for 
encrypting the messages during the initial handshake.

The plain "record type" field has been retired when the new padding mechanism 
was introduced, with the idea of better protecting privacy. So the main 
question here is: how important is it to make handshake and application data 
messages indistinguishable? And is it realistic?
- The late handshake messages are "new ticket," "late client auth," and "key 
update." I guess the most sensitive of them is "late client auth?" Is it 
important that this be hidden within application data? Are "new ticket" and 
"key update" also considered privacy-sensitive?
- Beyond the plain record type, the message may also be identifiable by other 
traffic characteristics such as length or timing. While the length can be 
hidden using padding, this requires co-operation with the application layer, 
because TLS can hardly know what the characteristic traffic pattern of the 
particular application is. Is this, realistically, ever going to happen in a 
way that will significantly cover the characteristic pattern of the handshake 
messages?

In a nutshell, three possibilities for this are:
(a) Do not separate keys, i.e., set HTK = ATK. This makes cryptographic 
analysis harder and renders the protocol less modular, but it may have privacy 
advantages.
(b) Separate keys, set HTK != ATK, and resurrect the “record type” field to the 
extent that it allows to differentiate HTK-encrypted packets from ATK-encrypted 
packets. This seems the cryptographically cleanest way but may come with worse 
privacy guarantees.
(c) Separate keys, set HTK != ATK, leave “record type” field disabled, and 
trial-decrypt. This is messier than both of the above, but seems a possible 
compromise between modularity and privacy.

What do you think?

Thanks & best,
Björn


[1] 
http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme

--
Björn Tackmann
Postdoctoral Research Scholar
Computer Science & Engineering, UC San Diego





___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

[Eric Rescorla]

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 properties of PSK-based 0-RTT and DHE-based 0-RTT
> > are almost identical, but 0-RTT PSK has better performance properties and
> > is simpler to specify and implement. Note that this does not permanently
> > preclude supporting DHE-based 0-RTT in a future extension, but it would
> > not be in the initial TLS 1.3 RFC.
>
> This will remove a feature from the QUIC protocol, so I'd be
> interested in hearing the QUIC team's opinion.
>

I agree that this would be valuable.


Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm
> not sure if "simplier to specify" should be an important factor.
> However, "simpler to implement" is an important consideration. I am
> curious to know how we concluded that 0-RTT PSK is simpler to
> implement. Did anyone implement both 0-RTT modes and can compare the
> difficulties?
>

We have a prototype 0-RTT PSK implementation and have looked at but not yet
implemented 0-RTT DHE in NSS. Based on that, my sense is that the cost of
doing any 0-RTT is the bulk of the additional effort, but that if you have
PSK already, which you probably want for ordinary resumption, then the
incremental cost of 0-RTT with PSK is less than with DHE.


As for 0-RTT PSK having better performance, that comes at the cost of
> a previous full handshake with the server.


Yes, this is correct. However, that's the current design of 0-RTT DHE in
TLS 1.3 as well.



> Also, TLS 1.3 clients that
> want to do 0-RTT PSK across an application shutdown will need to deal
> with the harder problem of storing PSKs persistently.
>

Yes, that's the major delta.

-Ekr


>
> Wan-Teh Chang
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Tickets and cross protocol attacks

[David Benjamin]

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 session ids between TLS protocols. For example a client could use a
> ticket negotiated with a previous version of TLS with TLS1.3. This could
> result in interesting situations:
>

I agree that the spec should clearly forbid cross-version resumption. I
filed https://github.com/tlswg/tls13-spec/issues/136 some time ago about
this. It got closed since session resumption was reworked for 1.3, but it
doesn't look like the clarifications on matching versions ever happened,
just the removal of the bad client advice.

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:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9e189b9dc10786c755919e6792e923c584c918a1

No client implementation which I tested allowed a server to do this either.
They treated it as a fatal connection error. (Which also means there is no
reason for a server to do it because it will not work anyway.)


> 1. Bypassing client auth
> If a server restricts a super-secure resource only over TLS1.3 with client
> auth and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker
> has a SLOTH client impersonation attack against TLS1.2, they can get a TLS
> ticket from TLS1.2 connection issued by a server. The ticket would have the
> original client auth encrypted in it. The attacker could then use the
> ticket with TLS1.3 PSK resumption and authenticate as the original client.
>
> 2. PSK 0-RTT
> If the client agrees to use the ticket negotiated over a previous TLS1.2
> connection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An
> attacker that has a SLOTH attack for server impersonation could inject
> their own TLS ticket into the connection with a client in a TLS1.2
> handshake. The 0-RTT data would be encrypted with an attacker known key and
> they could decrypt the 0-RTT data. If the connection continues to use PSK,
> the attacker can decrypt more data, however if the connection uses PSK +
> (EC)DHE then the attackers capability will be limited to decrypting the
> 0-RTT data.
>
> 3. Using DROWN style attacks
> The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0
> - TLS1.2 handshake. This might cause interesting new attacks to open up
> where a TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server.
>
> Even if a server enforces strict key separation between different TLS
> versions (which is very difficult), if tickets or session ids are reusable
> across TLS versions either on the client or the server, I believe these
> types of attacks remain possible.
>
> We could consider adding a section detailing the requirements for tickets
> for security. Even though there is a recommended construction, we could
> require a few things for the security of TLS 1.3:
> 1. Adding original TLS version to the ticket, so that TLS1.3 server can
> reject tickets issued by previous versions to prevent client authentication
> forgeries
> 2. Restricting 0-RTT data to only be encrypted with PSKs issued during a
> previous TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted
> 3. If a PSK is set via a ticket or session id, PSK modes for both normal
> PSK as well as 0-RTT should be only used with the protocol it was first
> negotiated with and prevent fallback. For example if a client received a
> PSK from TLS1.3, it should not allow either 0-RTT or resumed handshakes
> using that ticket to fallback back to lower protocols.
>
> Before a client knows that a server supports TLS1.3 and if a client allows
> TLS1.2 fallbacks, I don't think there's anything we can do to prevent that
> downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently),
> however once TLS1.3 is negotiated, the above things will prevent downgrade
> to TLS1.2.
>

I disagree with point #3 and think the "prevent fallback" portion would be
a mistake. Possession of a TLS 1.3 session to offer should not disable TLS
1.2 if the client would have accepted this without that session.

It's the same as my complaint about RFC 5246 E.1's paragraph in the bug
linked earlier. While it is enticing to do away with TLS 1.2 this way, the
reality is deployments are messy and can be heterogeneous. The service may
be in the middle of deploying (or rolling back!) a change across many
machines. Or perhaps it's not as well-managed and simply has two completely
different machines behind it.

We've seen problems in Chrome due to version-locking behavior in OpenSSL
against real services with, say, one TLS 1.0 machine and one TLS 1.2
machine. They did not cross-resume sessions, but it doesn't matter. By the
time you find that out, the version has 

Re: [TLS] Narrowing the replay window

[Kyle Nekritz]

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 1 round trip.

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, March 29, 2016 6:29 AM
To: tls@ietf.org
Subject: [TLS] Narrowing the replay window

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 not ironclad, since the server needs to account for a round trip, but I 
think that would could probably get the window down to single-digit seconds.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwICAg=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=yV13qQWQtVr_en1cI1kcs4zRx07qsOQ4PNkMQFvEIQw=XQHs_Zge-MaIU6aeUJxO3PTm-2SGhf8O-AAoRKk_vws=
 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Tickets and cross protocol attacks

[Subodh Iyengar]

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 a ticket 
negotiated with a previous version of TLS with TLS1.3. This could result in 
interesting situations:

1. Bypassing client auth
If a server restricts a super-secure resource only over TLS1.3 with client auth 
and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker has a 
SLOTH client impersonation attack against TLS1.2, they can get a TLS ticket 
from TLS1.2 connection issued by a server. The ticket would have the original 
client auth encrypted in it. The attacker could then use the ticket with TLS1.3 
PSK resumption and authenticate as the original client.

2. PSK 0-RTT
If the client agrees to use the ticket negotiated over a previous TLS1.2 
connection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An attacker 
that has a SLOTH attack for server impersonation could inject their own TLS 
ticket into the connection with a client in a TLS1.2 handshake. The 0-RTT data 
would be encrypted with an attacker known key and they could decrypt the 0-RTT 
data. If the connection continues to use PSK, the attacker can decrypt more 
data, however if the connection uses PSK + (EC)DHE then the attackers 
capability will be limited to decrypting the 0-RTT data.

3. Using DROWN style attacks
The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0 - 
TLS1.2 handshake. This might cause interesting new attacks to open up where a 
TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server.

Even if a server enforces strict key separation between different TLS versions 
(which is very difficult), if tickets or session ids are reusable across TLS 
versions either on the client or the server, I believe these types of attacks 
remain possible.

We could consider adding a section detailing the requirements for tickets for 
security. Even though there is a recommended construction, we could require a 
few things for the security of TLS 1.3:
1. Adding original TLS version to the ticket, so that TLS1.3 server can reject 
tickets issued by previous versions to prevent client authentication forgeries
2. Restricting 0-RTT data to only be encrypted with PSKs issued during a 
previous TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted
3. If a PSK is set via a ticket or session id, PSK modes for both normal PSK as 
well as 0-RTT should be only used with the protocol it was first negotiated 
with and prevent fallback. For example if a client received a PSK from TLS1.3, 
it should not allow either 0-RTT or resumed handshakes using that ticket to 
fallback back to lower protocols.

Before a client knows that a server supports TLS1.3 and if a client allows 
TLS1.2 fallbacks, I don't think there's anything we can do to prevent that 
downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently), however 
once TLS1.3 is negotiated, the above things will prevent downgrade to TLS1.2.

Cheers,
Subodh Iyengar
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

[Hubert Kario]

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-56-bit-ciphersuites as Historic (in the sense of
> >>> RFC
> >>> 6101). It would start with
> >>> https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01
> >>> ,
> >>> but the ciphersuites 0x60 and 0x61 would be added also as they
> >>> were
> >>> implemented in OpenSSL.
> >>> 
> >>> Yuhong Bao
> >> 
> >> Hi
> >> 
> >> It would be possible but I’m wondering some things:
> >> 
> >> 1. Are the original authors interested, or are there alternative
> >> authors willing to take this on?
> >> 
> >> 2. What is the point?  All of the ciphersuites in there have been
> >> deprecated by some diediedie document or another, and no sane
> >> document author (here or elsewhere) would include any of these
> >> 56-bit
> >> ciphers in any profile for TLS that is intended to provide
> >> security.
> >> So what is the benefit?
> > 
> > 1. Showing why the code points are reserved.
> > 2. Having official list of code points which must not be enabled (so
> > 
> >   that scanners can be complete)
> 
> Right. But this draft does not include RC4, RC2, and a number of other
> bad IDEAs (pun intended), so it’s not a comprehensive list of things
> you shouldn’t be doing.

it's not a die-die-die document. It's a document that will add the IDs 
to https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

0x00,0x62 has no intrinsic meaning. TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA 
has.

What to do with them is second step.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Call for consensus: Removing 0-RTT client auth

[Sean Turner]

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 
authentication needs to be supported please indicate so now and provide your 
rationale.

J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

[Yoav Nir]

> 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 would start with
>>> https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 ,
>>> but the ciphersuites 0x60 and 0x61 would be added also as they were
>>> implemented in OpenSSL.
>>> 
>>> Yuhong Bao
>> 
>> Hi
>> 
>> It would be possible but I’m wondering some things:
>> 
>> 1. Are the original authors interested, or are there alternative
>> authors willing to take this on?
>> 
>> 2. What is the point?  All of the ciphersuites in there have been
>> deprecated by some diediedie document or another, and no sane
>> document author (here or elsewhere) would include any of these 56-bit
>> ciphers in any profile for TLS that is intended to provide security.
>> So what is the benefit?
> 
> 1. Showing why the code points are reserved.
> 2. Having official list of code points which must not be enabled (so
>   that scanners can be complete)

Right. But this draft does not include RC4, RC2, and a number of other bad 
IDEAs (pun intended), so it’s not a comprehensive list of things you shouldn’t 
be doing.

Yoav



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

[Peter Gutmann]

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 code includes 1K iterations of various PKC ops in mechanisms that
are sensitive to leading-zero truncation (PGP springs to mind) to detect this.
Without this, it's mostly blind luck as to whether your self-test hits the
1/256 one that triggers the problem.  Having to design coverage tests is hard
enough, but when you need to iterate them to find problems...

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

[Hubert Kario]

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-ietf-tls-56-bit-ciphersuites-01 ,
> > but the ciphersuites 0x60 and 0x61 would be added also as they were
> > implemented in OpenSSL.
> > 
> > Yuhong Bao
> 
> Hi
> 
> It would be possible but I’m wondering some things:
> 
> 1. Are the original authors interested, or are there alternative
> authors willing to take this on?
> 
> 2. What is the point?  All of the ciphersuites in there have been
> deprecated by some diediedie document or another, and no sane
> document author (here or elsewhere) would include any of these 56-bit
> ciphers in any profile for TLS that is intended to provide security.
> So what is the benefit?

1. Showing why the code points are reserved.
2. Having official list of code points which must not be enabled (so 
   that scanners can be complete)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Narrowing the replay window

[Martin Thomson]

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 not ironclad, since the server needs to account for a round trip,
but I think that would could probably get the window down to
single-digit seconds.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

[Martin Thomson]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls