Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

[Subodh Iyengar]

Our data suggests that during successful handshakes the clock skew of mobile 
devices is within a few hours, and is within years for unsuccessful cases. 
Having relative time thus is definitely better from the client's perspective. 

With this however, there is a tradeoff on the server. The expiry time for the 
config is signed into the server config itself. So if the server wants to 
expire its server config in a predictable way it probably needs to resign it 
periodically. This adds some operational issues on the server, for example 
performance, and becomes more operationally challenging in situations where 
there is cryptographic offloading to either a different process or a different 
box. If we can come up with a reasonable solution to the resigning problem, 
then relative time seems superior. 

Cheers,
Subodh Iyengar


From: TLS [tls-boun...@ietf.org] on behalf of Hubert Kario [hka...@redhat.com]
Sent: Thursday, July 23, 2015 4:16 AM
To: tls@ietf.org
Subject: Re: [TLS] Relative vs absolute ServerConfiguration.expiration_date

On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote:
> One of the topics of discussion at the WG discussion was whether
> ServerConfiguration.expiration_date should be an absolute or relative
> value. Subodh (CC) dug into our production data and found that nearly half
> of the TLS errors we see in production (end user to edge/origin) are due to
> date mismatch. This often occurs when people intentionally reset the clock
> on their phone, or for other various reasons.

> Due to the high rate of date mismatch errors we see, my preference would be
> that ServerConfiguration.expiration_date be a relative value instead of an
> absolute one. This provides the client an opportunity to correctly use a
> monotonic (or other similar) clock to minimizing exposure, without losing
> the value of the ServerConfiguration. Using an absolute value means that
> ServerConfiguration, for clients with invalid clocks, would essentially
> never be cacheable. These clients wouldn’t benefit from
> ServerConfiguration.

the hint on tickets is already relative, so +1 on relative in server
configuration too
--
Regards,
Hubert Kario
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

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

Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

[Subodh Iyengar]

One other proposal which is related is to make server config have relative time 
as well instead of absolute time. If we don't make this relative this 
expiration time might not be practically enforceable due to clock skew.

This enforcement is relevant in situations where compromise of the ephemeral 
server config key is not the same as compromising the long term private key, 
for example in a SSL key offloading infrastructure.

I do not think relative time introduces any new threats because the server 
still needs to prove possession of the private key to make new clients accept a 
server config. Thus a compromise of a server config key should only affect the 
initial data of clients who have cached a config modulo relative expiration 
time.

Subodh Iyengar

From: TLS [tls-boun...@ietf.org] on behalf of Benjamin Kaduk [bka...@akamai.com]
Sent: Tuesday, February 23, 2016 10:43 AM
To: Nick Sullivan; tls@ietf.org
Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

On 02/23/2016 11:42 AM, Nick Sullivan wrote:
My proposed change is to change the session ticket lifetime hint to a strict 
lifetime along the lines of the ServerConfiguration:


But leave it as a relative time, contrasting the absolute expiration time of 
the server configuration -- why not go for full-out parallelism?

-Ben

ticket_lifetime
Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte 
order from the time of ticket issuance. Servers MUST NOT use any value more 
than 604800 seconds (7 days). The value of zero indicates that the ticket 
should be discarded immediately. Clients MUST NOT cache session tickets for 
longer than 7 days, regardless of the ticket_lifetime. It MAY delete the ticket 
earlier based on local policy. A server MAY treat a ticket as valid for a 
shorter period of time than what is stated in the ticket_lifetime.

The full change is on Github as a pull request:
https://github.com/tlswg/tls13-spec/pull/424<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_424&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=S4CFPnNBaB7swATOHOzQkIlnUwgvBaVelRwg-VJzz-g&s=IsvSLMYBUZf_IWLI_bWWg7vpIQk-qSFCzIvsMw7in_I&e=>

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

Re: [TLS] Remove DH-based 0-RTT

[Subodh Iyengar]

Removing DH based 0-RTT would make it more important to make the lifetime of 
the ticket enforced.

One interesting difference is that DH based 0-RTT requires proof of possession 
of the private key for the client to accept the connection, however PSK based 
0-RTT might not be associated with a certificate at all. Thus the only way to 
prove that the key is still fresh is to limit the time that the PSK is valid 
and strictly bound that time. Unless we add a way for the client to require a 
server authentication during PSK resumption.

This is relevant in situations where compromise of the ephemeral key does not 
mean that the long term private key has been compromised like in ssl offloading 
type scenarios.

Subodh Iyengar

From: TLS [tls-boun...@ietf.org] on behalf of Eric Rescorla [e...@rtfm.com]
Sent: Tuesday, February 23, 2016 11:42 PM
To: Watson Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT



On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk 
mailto:h...@ee.technion.ac.il>> wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett 
> mailto:davemgarr...@gmail.com>>
> wrote:
>>
>> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
>> > I propose that we remove DH-based 0-RTT from TLS 1.3.
>> >
>> > As ekr's previous mail noted, the security properties of PSK-based
>> > 0-RTT and DH-based 0-RTT are almost identical.  And DH-based 0-RTT is
>> > much more complex.
>> >
>> > For those who love DH-based 0-RTT, and I know that some people are
>> > fans, here's something that might make you less sad about removing it
>> > from the core spec.  You can use DH out of band to negotiate a PSK.
>> > You might even do this as an extension to TLS, but that's of less
>> > value.
>>
>> I think there is a good argument for moving DH 0RTT into a TLS extension.
>> Implementations that are explicitly not going to use it should not be
>> expected to implement it and risk screwing it up. If we accept that premise
>> that online DH 0RTT will be unlikely in practice, then we would be
>> specifying it at least primarily for out-of-band use, and doing it via an
>> extension will probably be cleaner and safer.
>
>
> Combining this comment (which I agree with) with the following comment from
> Watson in another thread:
>
>>
>  If they rely on extensions then either those
>>
> extensions need to be included in the security proofs, or we need to
>>
> make clear that they are not as secure as TLS 1.3, and that
>>
> implementations which enable both of them can get completely wrecked
>>in new and exciting ways.
>
> We get that even if it is decided not to include the DH-based 0-RTT as part
> of mandatory-to-implement TLS 1.3, it should be defined as an extension and
> as part of the TLS 1.3 document. Leaving the reduction from this case to PSK
> (as Martin suggested) to popular imagination is too dangerous. By including
> it as part of TLS 1.3 official text we also encourage the groups that are
> currently analyzing the protocol to include this specific mechanism in their
> analysis. If they find something wrong with it then even more reason to do
> the analysis.
>
>
>>
>> I would still prefer it be defined in the TLS 1.3 specification document,
>> though optional.
>
>
> I suggest to also define TLS 1.3-EZ.
> A subset of core safe functionality that should address the majority of the
> usage cases.

I strongly encourage this proposal, and will even massacre the
markdown to attempt it.

Great. Let's sync up as we get a little closer to done.


I also commit to implementing TLS 1.3-EZ in
Go, and possibly in C based on Amazon's s2n. (A trustable X509 library
in C is still beyond my reach, so that C might be server-only).

I believe Richard Barnes has already started something along these lines,
so maybe you guys could join forces (not sure how confident he is in
it).

https://github.com/bifurcation/mint

This library currently interoperates with my experimental implementation
in NSS.

-Ekr


>
> Hugo
>
>
>>
>>
>>
>> Dave
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org<mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>
>
>
>
> ___

Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

[Subodh Iyengar]

There are 2 different issues being discussed here, lifetime of tickets and 
configs.

It is probably better to revisit the discussion of whether or not to have 
ServerConfig be relative or absolute after it is decided whether or not the DH 
0-RTT handshake will still exist.

The general point I wanted to make is that relative times are practically 
enforceable by clients.
For ticket_lifetime, which already is relative time, it is desirable to change 
them from an informative only behavior to being usable by clients, which Nick's 
pull request does.  Enforcing relative time for things like tls ticket validity 
time has better security properties for certain use cases like key offloading. 
Nick's pull request limits the time clients can cache it to 7 days which is 
reasonable middle ground and clients can decide to delete the ticket earlier.

I +1 the pull request.

Subodh Iyengar

From: TLS [tls-boun...@ietf.org] on behalf of Salz, Rich [rs...@akamai.com]
Sent: Monday, February 29, 2016 9:15 AM
To: m...@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

> What should be memorized/stored is absolute time-of-creation.

If the structure itself includes absolute times, then the memorization is 
(trivially) simpler.

> How long to consider it valid, is a local issue and not necessarily a constant
> validity period over time.

True.  Treat it as a hint from the server.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qqjUPIB9UGopotanCAwZnp0-jzGVYglIQZJF_t3gzPA&s=-sv0ZsIso_1M3gqRtmLNdhvCr50uDuFVHhzZro2d4j8&e=

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

[TLS] potential attack on TLS cert compression

[Subodh Iyengar]

Antoine and I were discussing draft-ietf-tls-certificate-compression over lunch 
today and we think there could be a potential attack on the current scheme 
which could be fixed with some changes.


Currently the CompressedCertificate is included in the handshake transcript.. 
However let's say a server fragments it's compressed certificate message into 
multiple records, and an attacker has found a vulnerability in the 
decompression function based on the timing in which the data is delivered to 
the decompression function due to a race condition. They could manipulate the 
CompressedCertificate message to manipulate the peer to decompress something 
other than what the sender sent even though the handshake transcript remains 
the same.

Normally this wouldn't matter if there were only certificates, however we have 
extensions in certificates which could manipulate how certificates can be 
interpreted. This creates a time to check to time to use bug which relies on 
the security of the decompression function to determine the security of the TLS 
exchange.


This is definitely a far fetched attack I don't think this is desirable to base 
the security of TLS on the security of a decompression function. This is 
probably solvable by hashing in the uncompressed cert message into the TLS 
transcript rather than the compressed message which seems more secure because 
it enforces that the client and server have the same state of the uncompressed 
message.


Subodh

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

Re: [TLS] potential attack on TLS cert compression

[Subodh Iyengar]

Ya I think you have the right idea. The former attack is the one that I'm more 
concerned about, i.e. compression libraries almost always provide streaming 
interfaces. Another case is that TLS implementations which are the users of 
some decompression api might also provide the frames to the decompression 
library in non-deterministic order.


With draft-25 we've authenticated the record header so the attacker can't force 
the data to be processed in a different chunking than the server which is why I 
mentioned that the only leverage the attacker has is timing. We missed the 
draft-23 bus on pointing out the attack 😊


Compression libraries can get complicated especially ones that use multiple 
cores do speed up decompression. It's not necessary that the library does ASN.1 
streaming, but you can imagine an implementation where a lower layer could 
stream the compressed cert message into a uncompressed buffer, and then send 
the uncompressed buffer to an ASN.1 parser. The attack assumed malleability in 
the former process because records are already streaming so the data can be 
parsed in a streaming way.


I admit this depends on the implementation and various other magic factors, 
however it seems unfortunate to base the security of TLS on the security of the 
decompression function and the way that an implementation might use the 
decompression function, when there seems to be a simple? way to solve it.


Subodh


From: David Benjamin 
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] potential attack on TLS cert compression

To make sure I understand the issue, the concern is that your decompression 
function provides a chunk-by-chunk interface, there's a bug and the division 
into chunks produces a different result? Or are you suggesting that, with the 
same chunking pattern, the result is still non-deterministic somehow? I could 
imagine the former kind of bug, but I'm not sure about the latter.

If the former, I don't see follow how an attacker might control the division 
into records. It's easy in TLS 1.2, but we punted compression from 1.2, and in 
TLS 1.3, the handshake records are encrypted.

Either way, I'm also not sure I've ever seen a TLS stack that processes 
messages chunk-by-chunk. Usually the message is reassembled from multiple 
records, if necessary, and then only processed when complete. I'm sure, in the 
vast space of implementations, such a stack exists, but it seems the same 
transcript consideration then applies without compression. Otherwise you'd need 
a correct streaming version of all TLS message parsing, ASN.1, and whatever 
else TLS calls into. Those are ad-hoc whereas decompression implementations are 
at least intended to stream correctly. (Then again, decompression is also a bit 
more complicated, probably.)

Did I understand the issue correctly?

On Thu, Mar 22, 2018 at 12:04 PM Subodh Iyengar 
mailto:sub...@fb.com>> wrote:

Antoine and I were discussing draft-ietf-tls-certificate-compression over lunch 
today and we think there could be a potential attack on the current scheme 
which could be fixed with some changes.


Currently the CompressedCertificate is included in the handshake transcript. 
However let's say a server fragments it's compressed certificate message into 
multiple records, and an attacker has found a vulnerability in the 
decompression function based on the timing in which the data is delivered to 
the decompression function due to a race condition. They could manipulate the 
CompressedCertificate message to manipulate the peer to decompress something 
other than what the sender sent even though the handshake transcript remains 
the same..

Normally this wouldn't matter if there were only certificates, however we have 
extensions in certificates which could manipulate how certificates can be 
interpreted. This creates a time to check to time to use bug which relies on 
the security of the decompression function to determine the security of the TLS 
exchange.


This is definitely a far fetched attack I don't think this is desirable to base 
the security of TLS on the security of a decompression function. This is 
probably solvable by hashing in the uncompressed cert message into the TLS 
transcript rather than the compressed message which seems more secure because 
it enforces that the client and server have the same state of the uncompressed 
message.


Subodh


___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=yZJNzjyJxeApb_xGj4SpKqxVUsFz0DyksR6sTiyXlR4&s=sdRxUMYuldew6KHHPkg-b0LPwURwzvSq_9t95kFD2ss&e=>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] potential attack on TLS cert compression

[Subodh Iyengar]

Former and latter is a horrible way to refer to attacks :)
what I really meant is that when a receiver processing of timing of same TLS 
record chunks triggers a bug in the decompressor.


Subodh


From: TLS  on behalf of Subodh Iyengar 
Sent: Thursday, March 22, 2018 10:11:33 AM
To: David Benjamin
Cc: tls@ietf.org
Subject: [Potential Spoof] Re: [TLS] potential attack on TLS cert compression


Ya I think you have the right idea. The former attack is the one that I'm more 
concerned about, i.e. compression libraries almost always provide streaming 
interfaces. Another case is that TLS implementations which are the users of 
some decompression api might also provide the frames to the decompression 
library in non-deterministic order.


With draft-25 we've authenticated the record header so the attacker can't force 
the data to be processed in a different chunking than the server which is why I 
mentioned that the only leverage the attacker has is timing. We missed the 
draft-23 bus on pointing out the attack 😊


Compression libraries can get complicated especially ones that use multiple 
cores do speed up decompression. It's not necessary that the library does ASN.1 
streaming, but you can imagine an implementation where a lower layer could 
stream the compressed cert message into a uncompressed buffer, and then send 
the uncompressed buffer to an ASN.1 parser. The attack assumed malleability in 
the former process because records are already streaming so the data can be 
parsed in a streaming way.


I admit this depends on the implementation and various other magic factors, 
however it seems unfortunate to base the security of TLS on the security of the 
decompression function and the way that an implementation might use the 
decompression function, when there seems to be a simple? way to solve it.


Subodh


From: David Benjamin 
Sent: Thursday, March 22, 2018 9:58:57 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] potential attack on TLS cert compression

To make sure I understand the issue, the concern is that your decompression 
function provides a chunk-by-chunk interface, there's a bug and the division 
into chunks produces a different result? Or are you suggesting that, with the 
same chunking pattern, the result is still non-deterministic somehow? I could 
imagine the former kind of bug, but I'm not sure about the latter.

If the former, I don't see follow how an attacker might control the division 
into records. It's easy in TLS 1.2, but we punted compression from 1.2, and in 
TLS 1.3, the handshake records are encrypted.

Either way, I'm also not sure I've ever seen a TLS stack that processes 
messages chunk-by-chunk. Usually the message is reassembled from multiple 
records, if necessary, and then only processed when complete. I'm sure, in the 
vast space of implementations, such a stack exists, but it seems the same 
transcript consideration then applies without compression. Otherwise you'd need 
a correct streaming version of all TLS message parsing, ASN.1, and whatever 
else TLS calls into. Those are ad-hoc whereas decompression implementations are 
at least intended to stream correctly. (Then again, decompression is also a bit 
more complicated, probably.)

Did I understand the issue correctly?

On Thu, Mar 22, 2018 at 12:04 PM Subodh Iyengar 
mailto:sub...@fb.com>> wrote:

Antoine and I were discussing draft-ietf-tls-certificate-compression over lunch 
today and we think there could be a potential attack on the current scheme 
which could be fixed with some changes.


Currently the CompressedCertificate is included in the handshake transcript. 
However let's say a server fragments it's compressed certificate message into 
multiple records, and an attacker has found a vulnerability in the 
decompression function based on the timing in which the data is delivered to 
the decompression function due to a race condition. They could manipulate the 
CompressedCertificate message to manipulate the peer to decompress something 
other than what the sender sent even though the handshake transcript remains 
the same..

Normally this wouldn't matter if there were only certificates, however we have 
extensions in certificates which could manipulate how certificates can be 
interpreted. This creates a time to check to time to use bug which relies on 
the security of the decompression function to determine the security of the TLS 
exchange.


This is definitely a far fetched attack I don't think this is desirable to base 
the security of TLS on the security of a decompression function. This is 
probably solvable by hashing in the uncompressed cert message into the TLS 
transcript rather than the compressed message which seems more secure because 
it enforces that the client and server have the same state of the uncompressed 
message.


Subodh


__

Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

[Subodh Iyengar]

I merged all of these changes into master since it looked like no-one seemed to 
have strong opinions against them and they seemed like quite reasonable changes.


I'm about to cut a draft-02 with these changes if no-one has strong opinions 
against. https://github.com/tlswg/tls-subcerts/


Subodh


From: TLS  on behalf of Patton,Christopher J 

Sent: Tuesday, July 24, 2018 11:04:27 AM
To: Ilari Liusvaara
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts


Aww, I see your point. You're right, it should be that crit=true if and only if 
crit=true.


> Actually, what usecase do strict certificates serve anyway? I can not

> figure out any usecase that would make much sense to me. Dealing with
> server endpoints that are capable of LURK but not proof-of-possession
> nor is the keyserver capable of format-checking?

The point was to enforce that, if a delegation certificate is offered in a 
handshake, then a DC must be negotiated in that handshake. I wasn't actually 
there, but I'm told that this feature was brought up at IETF. It doesn't seem 
like there's a clean way to do this, and I'm not sure this feature is worth the 
added complexity.

I'm going to propose we drop the strict flag and let the critical bit be 
optional for the extension. What do you think?

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

[TLS] OID for delegated credentials

[Subodh Iyengar]

We've been kicking this can down the road for a while, but we probably should 
choose an OID for Delegated credentials


So far we've been doing interop with Cloudflare's OID of 1.3.6.1.4.1.44363.44.  
I'd be fine with putting that as the final OID the draft. Does anyone have any 
thoughts on whether we should / should not do this and use a different OID 
instead.


Cheers,

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

Re: [TLS] draft-ietf-tls-subcerts-01: some nits a question

[Subodh Iyengar]

Ya you're right here it is the DER-encoded SPKI and opaque 
ASN.1_subjectPublicKeyInfo is the right way to go.


Thanks,

Subodh


From: TLS  on behalf of Sean Turner 
Sent: Thursday, August 9, 2018 11:34:17 AM
To: tls@ietf.org
Subject: [TLS] draft-ietf-tls-subcerts-01: some nits a question

Hi,

I submitted a PR to address some nits I noticed:
https://github.com/tlswg/tls-subcerts/pull/17

One question:

In s3, public_key is the same thing as RawPublicKey in RFC 7250, i.e., they are 
both DER-encoded SPKI from RFC5280? If it is, does it make sense to reuse:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1> ?
If not, shouldn’t
public_key<0..2^16-1>;
be
public_key<1..2^16-1>;
or
public_key<1..2^24-1>

spt

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=IrOKyHv0mMG3XQlDR58bcZJrllo1irdlbauz8t892yI&s=WCIr65m_Feq1ii72j9Ec0ftL44J0j4f-3zWbbZgcAjU&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-wood-tls-external-psk-importer-00

[Subodh Iyengar]

I brought up an alternate construction in BKK for 
draft-wood-tls-external-psk-importer-00 which might have some potentially 
better properties. I didn't get time to explain then, so here it is:

One issue I think with the current construction in the draft with external psk 
is that if the client uses the external psk with a different hash function due 
to configuration error, then it turns into a fatal connection error because TLS 
endpoints are required to tear down the connections on binder mismatch. The 
client does not recover until it stops using the external psk..

An alternate approach to solve this could be to have a construction like:

[hash of (psk identity + ImportedIdentity)] [psk identity]

A server that uses the psk would perform the following steps during the 
resumption


  1.  Negotiate the cipher suite to use
  2.  If an external psk is used, strip off the first hash length of the psk 
identity where the hash length depends on the cipher suite.
  3.  Compute the hash of pskidentity + imported identity and compare it 
against (2)
  4.  If it doesn't match, don't use the PSK and fallback to full handshake..

I think this a subtle change, because if you treat this case as if you were not 
willing to use the PSK, then you can ignore the binder. This might be 
operationally easier to deploy and reason about than a hard failure.

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

Re: [TLS] draft-wood-tls-external-psk-importer-00

[Subodh Iyengar]

Ya I think failing hard depends on the use case for the external psk. For 
example if external psk is your own source of identity then ya you can't really 
fallback, however if you are using external psk as an optimization or something 
else, then falling back might be desirable.

Subodh

From: Christopher Wood 
Sent: Monday, November 5, 2018 6:56:57 PM
To: Subodh Iyengar
Cc: 
Subject: Re: [TLS] draft-wood-tls-external-psk-importer-00

On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar  wrote:
>
> I brought up an alternate construction in BKK for 
> draft-wood-tls-external-psk-importer-00 which might have some potentially 
> better properties. I didn't get time to explain then, so here it is:
>
> One issue I think with the current construction in the draft with external 
> psk is that if the client uses the external psk with a different hash 
> function due to configuration error, then it turns into a fatal connection 
> error because TLS endpoints are required to tear down the connections on 
> binder mismatch. The client does not recover until it stops using the 
> external psk.
>
> An alternate approach to solve this could be to have a construction like:
>
> [hash of (psk identity + ImportedIdentity)] [psk identity]
>
> A server that uses the psk would perform the following steps during the 
> resumption
>
> Negotiate the cipher suite to use
> If an external psk is used, strip off the first hash length of the psk 
> identity where the hash length depends on the cipher suite.
> Compute the hash of pskidentity + imported identity and compare it against (2)
> If it doesn't match, don't use the PSK and fallback to full handshake.
>
>
> I think this a subtle change, because if you treat this case as if you were 
> not willing to use the PSK, then you can ignore the binder. This might be 
> operationally easier to deploy and reason about than a hard failure.

Thanks for writing this down! This is certainly an interesting
proposal. That said, in cases where one might use external PSKs,
failing hard seems like a fine (and probably preferred?) outcome. I'd
be happy to hear of cases where one might want to fall back to a full
handshake.

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

Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

[Subodh Iyengar]

Thanks for bringing these up Watson


>The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusable, and the
signer of delegated credentials needs to accept a new version of TLS
as valid before the extension can be used with a new version. This is
similar to the issues prompting
draft-wood-tls-external-psk-importer-00 where PSKs depend on
negotiated parameters, and thus are difficult to use in practice.


Usually the negotiation happens during the processing of the client hello.

The certificate decision gets made a later. Is there a specific implementation 
detail

you're concerned about.


I think the negotiation of TLS version should be done first before deciding to 
use

DCs, and this needs to be done anyway because DCs are only valid TLS 1.3 and 
higher.


The existing set of creds would become invalid with a future version of TLS..

The method by which the TLS terminating server receives the DC is out of scope 
of this

document, however I hope people implement some sort of structure to their 
backend like


DC_objs = [ DC_obj1, DC_obj2,. ...]

DC_obj = { tls_version, private_key, DC structure, .etc.. }


which would make it so that they would automatically get new creds when they 
are updated.


Also there is the option of falling back to LURK style service if the DC 
doesn't exist. I wonder

if there is anything I'm missing here. The original rationale around DCs being 
bound to version

was to be able to preventing some attack on the current version of TLS which 
might expose an

oracle to be used against a future version of TLS that might fix it (like 
DROWN). If we think that this is not super

useful since we will never have oracle attacks in TLS 1.3, we can remove it as 
well.

> The second is that the DelegatedCredential indicates the algorithm
that was used to sign it. Someone who is a bit careless when
implementing might take that literally with the result that they
verify a DelegatedCredential with RSA algorithm and the certificate is
really an ECDSA certificate. I'll submit a PR with text for security
considerations/rewording the verification steps.


That would be great.


Subodh


From: TLS  on behalf of Watson Ladd 

Sent: Tuesday, January 15, 2019 5:13:17 PM
To: tls@ietf.org
Subject: [TLS] Version pinning and indicating the signing algorithm in 
draft-ietf-tls-subcerts-02

Dear TLS WG,

While we were implementing delegated credentials we came up with the
following two problems. I thank David Benjamin for communicating the
first to me.

The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusable, and the
signer of delegated credentials needs to accept a new version of TLS
as valid before the extension can be used with a new version. This is
similar to the issues prompting
draft-wood-tls-external-psk-importer-00 where PSKs depend on
negotiated parameters, and thus are difficult to use in practice.

The second is that the DelegatedCredential indicates the algorithm
that was used to sign it. Someone who is a bit careless when
implementing might take that literally with the result that they
verify a DelegatedCredential with RSA algorithm and the certificate is
really an ECDSA certificate. I'll submit a PR with text for security
considerations/rewording the verification steps.

Sincerely,
Watson

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=ZnSY03FUuGDkpTjaYw9S-739-JBe-iqsIaeiu32GMvU&s=sxKHoBLptrk0e_hub5oKvfRWf1akiS095tuHtXLCZ38&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

[Subodh Iyengar]

I don't feel too strongly about the tls version binding and I'd be fine with 
removing it to favor operational simplification.


Subodh


From: TLS  on behalf of Martin Thomson 

Sent: Tuesday, January 15, 2019 7:39:44 PM
To: tls@ietf.org
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in 
draft-ietf-tls-subcerts-02

On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> Usually the negotiation happens during the processing of the client hello..

I don't think that the problem here is a code problem.  It's an operational one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be made 
in isolation.  You decide to flip the switch and flip it.  But if you are doing 
delegated credentials, deploying a new version depends on having a fallback in 
place for that version, or getting the vendor of delegated credentials to start 
supplying new credentials.  And that assumes that all the necessary stores are 
keyed correctly (though this highlights the case where that might not happen), 
and the code has been written.  It's not that it's impossible, but more that it 
complicates what was previously uncomplicated.

As you say, the decision to use a delegated credential is fairly simple.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=LwnVFi-5giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ticket lifetimes

[Subodh Iyengar]

In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This had 
several original motivations including reducing the time that a ticket is 
reused (for privacy or PFS). Another major motivation for this was to limit the 
exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a 
STEK locally, but the keyless SSL server remotely, then the theft of a STEK 
would presumably limit the MITM capabilities to the ticket lifetime.

However thinking about it some more because of the renewal capability of 
tickets in TLS 1.3, an entity owning the STEK could just re-issue new tickets 
forever on a resumed connection. This would look to the client as a new ticket 
and it would refresh its lifetime on the ticket. Thereby a MITM could intercept 
connections to users that have been to the server with the STEK. I'm wondering 
whether it might be useful to define a mechanism to limit the lifetime of all 
ticket resumption across all resumptions from the original connection instead 
of just the limited per ticket lifetime.

Subodh


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

Re: [TLS] ticket lifetimes

[Subodh Iyengar]

> Since clients already store tickets, could they not also store the
time of original ticket issuance and cap the resumption window to N
(7) days from that point? That is, it seems clients could implement
this behavior without any protocol support.

Correct, however the server currently provides a value for this, and clients do 
not enforce a lower bound on this. 7 days is an upper bound.
Servers would provide a much lower value than 7 days practically.

If I'm understanding your suggestion correctly, you're suggesting that clients 
change the meaning of ticket_lifetime_hint?
That is not just limit it to the scope of the ticket but the entire TLS 
session? That would be fine to by me, however might break some folks.

Subodh

From: Christopher Wood 
Sent: Monday, January 28, 2019 9:57 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes

On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar  wrote:
>
> In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This 
> had several original motivations including reducing the time that a ticket is 
> reused (for privacy or PFS). Another major motivation for this was to limit 
> the exposure of servers that use keyless ssl like mechanisms, i.e. if they 
> kept a STEK locally, but the keyless SSL server remotely, then the theft of a 
> STEK would presumably limit the MITM capabilities to the ticket lifetime.
>
> However thinking about it some more because of the renewal capability of 
> tickets in TLS 1.3, an entity owning the STEK could just re-issue new tickets 
> forever on a resumed connection. This would look to the client as a new 
> ticket and it would refresh its lifetime on the ticket. Thereby a MITM could 
> intercept connections to users that have been to the server with the STEK.. 
> I'm wondering whether it might be useful to define a mechanism to limit the 
> lifetime of all ticket resumption across all resumptions from the original 
> connection instead of just the limited per ticket lifetime.

Since clients already store tickets, could they not also store the
time of original ticket issuance and cap the resumption window to N
(7) days from that point? That is, it seems clients could implement
this behavior without any protocol support.

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

Re: [TLS] ticket lifetimes

[Subodh Iyengar]

> If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Ya I think that'd need a new draft either way. Can definitely write that up
if people don't think it's the worst idea in the world.

Subodh

From: Christopher Wood 
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes

On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar  wrote:
>
> > Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N
> (7) days from that point? That is, it seems clients could implement
> this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and clients 
> do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggesting that 
> clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TLS 
> session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> ________
> From: Christopher Wood 
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar  wrote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This 
> > had several original motivations including reducing the time that a ticket 
> > is reused (for privacy or PFS). Another major motivation for this was to 
> > limit the exposure of servers that use keyless ssl like mechanisms, i.e. if 
> > they kept a STEK locally, but the keyless SSL server remotely, then the 
> > theft of a STEK would presumably limit the MITM capabilities to the ticket 
> > lifetime.
> >
> > However thinking about it some more because of the renewal capability of 
> > tickets in TLS 1.3, an entity owning the STEK could just re-issue new 
> > tickets forever on a resumed connection. This would look to the client as a 
> > new ticket and it would refresh its lifetime on the ticket. Thereby a MITM 
> > could intercept connections to users that have been to the server with the 
> > STEK. I'm wondering whether it might be useful to define a mechanism to 
> > limit the lifetime of all ticket resumption across all resumptions from the 
> > original connection instead of just the limited per ticket lifetime.
>
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N
> (7) days from that point? That is, it seems clients could implement
> this behavior without any protocol support.
>
> Best,
> Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ticket lifetimes

[Subodh Iyengar]

> Wouldn't this issue also be mitigated by requiring the server to 
> re-authenticate during resumption with the certificate once in a while?

I think it's probably just easier to drop the resumption completely.

> This two-lifetime thing is actually already what we implement in BoringSSL. 😊

Fantastic. Would it help to have an extension to set a lower bound on this 
value, or just make it more painful?

Subodh

From: David Benjamin 
Sent: Tuesday, January 29, 2019 1:02 PM
To: Nick Sullivan
Cc: Subodh Iyengar; tls@ietf.org
Subject: Re: [TLS] ticket lifetimes

This two-lifetime thing is actually already what we implement in BoringSSL. :-) 
We track both a lifetime for the ticket (one day) and also for the original 
authentication the ticket roots up to (one week). The lifetime of the ticket is 
bounded by both these values, and the latter is not extendable on renew.

On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan 
mailto:40cloudflare@dmarc.ietf.org>> 
wrote:
Wouldn't this issue also be mitigated by requiring the server to 
re-authenticate during resumption with the certificate once in a while?

Existing servers won't do this, so I see this less as a mitigation and more as 
an optimization to plug the one-week-cliff that the fix produces. But, yeah, 
that would be handy. (Probably something like: "re"-auth'd identity apply to 
tickets, PSK applies to connection. Client sends an extension to advertise 
we're nearing the unrenewable bound.)

David

Nick

On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar 
mailto:sub...@fb.com>> wrote:
> If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Ya I think that'd need a new draft either way. Can definitely write that up
if people don't think it's the worst idea in the world.

Subodh

From: Christopher Wood 
mailto:christopherwoo...@gmail.com>>
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] ticket lifetimes

On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar 
mailto:sub...@fb.com>> wrote:
>
> > Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N
> (7) days from that point? That is, it seems clients could implement
> this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and clients 
> do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggesting that 
> clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TLS 
> session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> 
> From: Christopher Wood 
> mailto:christopherwoo...@gmail.com>>
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org<mailto:tls@ietf.org>
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar 
> mailto:sub...@fb.com>> wrote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This 
> > had several original motivations including reducing the time that a ticket 
> > is reused (for privacy or PFS). Another major motivation for this was to 
> > limit the exposure of servers that use keyless ssl like mechanisms, i.e. if 
> > they kept a STEK locally, but the keyless SSL server remotely, then the 
> > theft of a STEK would presumably limit the MITM capabilities to the ticket 
> > lifetime.
> >
> > However thinking about it some more because of the renewal capability of 
> > tickets in TLS 1.3, an entity owning the STEK could just re-issue new 
> > tickets forever on a resumed connection. This would look to the client as a 
> > new ticket and it would refresh its lifetime on the ticket. Thereby a MITM 
> > could intercept connections to users that have been to the server with the 
> > STEK. I'm wondering whether it might be useful to define a mechanism to 
> > limit the lifetime of all ticket resumption across all resumptions from the 
> > original connection instead of just the limited per ticket lifetime.
>
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N
> (7) days from that point? That is, it seems clients could implement
> th

Re: [TLS] ticket lifetimes

[Subodh Iyengar]

(Did you mean upper bound?)
> Na I meant lower bound. That is such an extension would be useless if the 
> time the server mentioned > time the client decided to cache it. However the 
> server might advertise a time < time the client decided to cache it, in which 
> it would be useful.

> I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on 
> the renewability, but apparently that's not how others read it!
>
Though, I guess, having not specified it this way from the start, the server 
can't be sure the client honors the extension. I don't know what consequences 
that has for server-preference scenario.

Yup I think there is a disconnect between the intention of the server operator 
and the protocol. That is the server operator would like to have only 7 day 
uses of the PSK, however unbeknownst to then, their library is renewing the 
ticket and extending the lifetime of the PSK. This disconnect exists in both 
TLS 1.2 and 1.3, however for TLS 1.2 the renewal of tickets is less widely 
deployed than it should be because of some historic client intolerance of it.

I think the interpretation that the lifetime applies to the current ticket only 
is the more common interpretation. I did a short study of several TLS 1.3 
implementation shandling of ticket lifetimes by staring at some code really 
intensely:

OpenSSL:
Leaves ticket management on the client to the caller via callbacks and doesn't 
enforce anything by itself.

NSS:
Looks like it treats the lifetime of each ticket independently and enforces the 
ticket lifetime.

https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#459
<https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslnonce.c#726>https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslnonce.c#1202
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#4661


OpenJDK:
Ignores lifetime hint after checking that it is < 7 days and then uses a jdk 
specified timeout which is a default of 1 day

http://hg.openjdk.java.net/jdk/jdk11/file/68fa3d4026ea/src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java#l336
http://hg.openjdk.java.net/jdk/jdk11/file/68fa3d4026ea/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#l65


boringssl:

Has the ability to use an internal session cache. Before it uses a ticket it 
checks the session timeout against current time. Everytime it receives a new 
session ticket it clamps the SSL_SESSION's timeout using 
ssl_session_rebase_time and then clears any timed out tickets with 
SSL_CTX_flush_sessions.

Fizz:

Treats each ticket lifetime independently.

mbed tls:
Leaves it to caller with mbedtls_ssl_conf_session_cache.  However the API 
doesn't allow mbedtls to verify whether or not the ticket_lifetime has exceeded 
and its up to the caller to verify this.

Seems like there is room for clarification on the ticket lifetime.

Subodh

From: David Benjamin 
Sent: Tuesday, January 29, 2019 2:52 PM
To: Subodh Iyengar
Cc: Nick Sullivan; tls@ietf.org
Subject: Re: [TLS] ticket lifetimes

On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar 
mailto:sub...@fb.com>> wrote:
> Wouldn't this issue also be mitigated by requiring the server to 
> re-authenticate during resumption with the certificate once in a while?

I think it's probably just easier to drop the resumption completely.

> This two-lifetime thing is actually already what we implement in BoringSSL. 😊

Fantastic. Would it help to have an extension to set a lower bound on this 
value, or just make it more painful?

(Did you mean upper bound?)

I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on the 
renewability, but apparently that's not how others read it! I don't care 
strongly either way about an extension to set a renewal bound, I think. A 
client is always free to tighten ticket lifetime policies unilaterally. We 
don't need an extension to advertise its policies unless we want to allow 
server to change their behavior in response. In the other direction, if we 
think the server may also have an opinion on renewability (you mention keyless 
things), a NewSessionTicket extension would be easy to support. The client 
would then use the more restrictive of the server's preferences and its local 
policy.

Though, I guess, having not specified it this way from the start, the server 
can't be sure the client honors the extension. I don't know what consequences 
that has for server-preference scenario.

(For completeness, BoringSSL doesn't allow TLS 1.2 ticket renewals to extend 
lifetime at all, only TLS 1.3, and TLS 1.2 lifetimes are capped much more 
tightly. Since TLS 1.2 resumption doesn't involve an ECDH operation, any 
concerns about a stale online signature are overshadowed by how much data the 

Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

[Subodh Iyengar]

Watson put up a PR https://github.com/tlswg/tls-subcerts/pull/21. I'm going to 
merge it tomorrow if there's no other feedback on it.
[https://avatars3.githubusercontent.com/u/1123811?s=400&v=4]<https://github.com/tlswg/tls-subcerts/pull/21>

Remove protocol from the structure by wbl · Pull Request #21 · 
tlswg/tls-subcerts<https://github.com/tlswg/tls-subcerts/pull/21>
As discussed in 
https://mailarchive.ietf.org/arch/msg/tls/h6DiWQvw7Cc0TXUtc7fNfB0fFNg and 
subsequent.
github.com

Subodh

From: Nick Sullivan 
Sent: Thursday, January 24, 2019 3:23 PM
To: Subodh Iyengar
Cc: Martin Thomson; tls@ietf.org
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in 
draft-ietf-tls-subcerts-02

I'm also fine with removing the field and would welcome a PR to that effect..

Putting in a version to protect a DC from future cross-protocol attacks that 
exploit TLS 1.3 smells a bit like over-engineering anyway.

Nick

On Tue, Jan 15, 2019 at 11:54 PM Subodh Iyengar 
mailto:sub...@fb.com>> wrote:

I don't feel too strongly about the tls version binding and I'd be fine with 
removing it to favor operational simplification.


Subodh


From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Martin Thomson mailto:m...@lowentropy.net>>
Sent: Tuesday, January 15, 2019 7:39:44 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in 
draft-ietf-tls-subcerts-02

On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> Usually the negotiation happens during the processing of the client hello..

I don't think that the problem here is a code problem.  It's an operational one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be made 
in isolation.  You decide to flip the switch and flip it.  But if you are doing 
delegated credentials, deploying a new version depends on having a fallback in 
place for that version, or getting the vendor of delegated credentials to start 
supplying new credentials.  And that assumes that all the necessary stores are 
keyed correctly (though this highlights the case where that might not happen), 
and the code has been written.  It's not that it's impossible, but more that it 
complicates what was previously uncomplicated.

As you say, the decision to use a delegated credential is fairly simple.

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=LwnVFi-5giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw&e=
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Q7cYq4juf3o-0YWxZtuLP7YJ8Kuwm-RSfp3YaF9dUn8&s=5P2RjQvDuXZivTnTQ3VNB0Gw49CwSQM97-EiDA9rmck&e=>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Delegated Credentials in Client certificates

[Subodh Iyengar]

Thanks for writing this up Nick. I support this change.


I think one interesting addition to this PR might be a discussion of what could 
happen if you use the same DC as both a client and server. I suspect this is 
what a lot of people might do in a datacenter environment and that this is safe 
(because of the signature context), but it might push people to think a little 
more about this topic.


Subodh


From: TLS  on behalf of Nick Sullivan 

Sent: Monday, July 8, 2019 1:12:00 PM
To: 
Subject: [TLS] Delegated Credentials in Client certificates

Hello TLSWG,

At previous meetings (and I think on the list?) there were requests to extend 
the Delegated Credentials in TLS 
(https://tools.ietf.org/html/draft-ietf-tls-subcerts)
 draft to support client certificates. This turns out to be a pretty minor 
change to the document. I've put up a PR:

https://github.com/tlswg/tls-subcerts/pull/26/files/a502f3055c3eefe59a4b36642cd062267ac0fff7

Let me know if there is opposition to this change. I'm planning on submitting 
-04 later today.

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

Re: [TLS] Delegated Credentials and Lawful Intercept

[Subodh Iyengar]

I do not entirely have context on for the requirements for something like that, 
I would imagine that the requirements would be significantly different and 
would need to be clearly defined.  However, at a high level
I'm not sure using a DC would be different from a provider obtaining a 
certificate for a short time duration instead. The DC use case for short 
duration is for increased reliability during normal service operation, however 
for these kinds of cases, which might be one off use cases, one could obtain a 
real certificate.

Subodh

From: TLS  on behalf of Florian Weimer 

Sent: Friday, November 1, 2019 1:13 PM
To: tls@ietf.org 
Subject: [TLS] Delegated Credentials and Lawful Intercept

Would it be possible to use delegated credentials to address lawful
intercept concerns, similar to eTLS?

Basically, the server operator would issue a delegated credential to
someone who has to decrypt or modify the traffic after intercepting
it, without having to disclose that backdoor in certificate
transparency logs.

And in a data center scenario, perhaps people feel more comfortable
loading those short-term credentials into their monitoring equipment.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=t6MvhK2KrPUKpEpozCS52kUs5eut_Pp-vjNPUa2R8gw&s=B6JEL8LBe1zq0d4EA0GgjAf8-H3ocB-zBLNnDTFkToM&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Subodh Iyengar]

I think the discussion about not understanding the implications of 
replayability is not correct. We are already in the situation where client data 
is replayable. For example if a mobile app encounters an HTTP error, it will 
probably retry the request throwing caution to the wind about replayability. 
Many popular HTTP libraries already do this very actively. In this scenario, 
even TLS1.2 replayability gurantees fall apart. At Facebook, we have several 
popular mobile applications and have plenty of experience dealing with retries. 

Like Kyle mentioned the thing that 0-RTT adds to this is infinite 
replayability. As mentioned in the other thread we have ways to reduce the 
impact of infinite replayable data for TLS, making it reasonably replay safe. 

Discussions of replayability in the void is impossible. There is no way TLS1.3 
is going to know all the use cases for replayability. That is an application 
layer decision. Thus we should have proposals at the application layer as well 
to express these properties to the transport layer, and we have one proposal 
for this which we're going to submit soon to HTTP WG. For example in the case 
of http, an application should express to the lower layers that the request 
that it is sending out is retry safe and that it is taking care of it. 

Developers are adults too. We can prevent them from shooting themselves in the 
foot by providing secure OFF by default option, but completely removing the 
option from them expressing these application properties to the underlying 
transport layer seems like treating them like children. I would hate to see 
0-RTT removed from the spec. This is something we at Facebook are looking 
forward to using and want to use immediately in browsers once it is available.

Subodh


From: TLS [tls-boun...@ietf.org] on behalf of Viktor Dukhovni 
[ietf-d...@dukhovni.org]
Sent: Monday, March 14, 2016 10:36 AM
To: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> On Mar 13, 2016, at 7:14 AM, Stephen Farrell  
> wrote:
>
> So, can people suggest ways in which we can figure out the impact
> of replayable data across all the many uses of TLS?

For idempotent (more strongly side-effect free) lookup protocols, 0-RTT makes
good sense.  There is no need for replay protection in the absence of
side-effects.  Web browsers are not the only use-case for TLS.

Similarly, in SMTP with STARTTLS the client's first data payload is a repeat
of an EHLO command that was already sent in the clear!  So one might for example
send the client's EHLO as 0-RTT replayable data.  Of course SMTP servers that
support 0-RTT data don't exist yet, but they may once 0-RTT becomes widely
available in SSL/TLS toolkits.

--
Viktor.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=WfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=qKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8&e=

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

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Subodh Iyengar]

> Is the "application" HTTP or a website? Many websites got bitten by nginx 
> changing how it treated certain retries due to ordering interactions. The 
> canonical example is a DELETE and a POST.

By application here I mean website html / JS which creates the http request and 
triggers the agent (browser) into making an http request or in the case of a 
mobile app the application code that calls the http library.

Currently the only way to express retry behavior in HTTP is by the method (i.e. 
whether it is idempotent or not), which as you pointed out may have unfortunate 
side effects, since it is not explicit. The proposal (at least one of them) is 
to add an explicit way to express retry safety in HTTP as an additional request 
property similar to method. This can be used by the agent (browser or http 
library) to decide whether or not to use 0-RTT for the http data. I'll link to 
it in this thread once it's posted.

Subodh


From: Watson Ladd [watsonbl...@gmail.com]
Sent: Monday, March 14, 2016 11:19 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data


On Mar 14, 2016 11:04 AM, "Subodh Iyengar" 
mailto:sub...@fb.com>> wrote:
>
> I think the discussion about not understanding the implications of 
> replayability is not correct. We are already in the situation where client 
> data is replayable. For example if a mobile app encounters an HTTP error, it 
> will probably retry the request throwing caution to the wind about 
> replayability. Many popular HTTP libraries already do this very actively. In 
> this scenario, even TLS1.2 replayability gurantees fall apart. At Facebook, 
> we have several popular mobile applications and have plenty of experience 
> dealing with retries.

Do they in fact fall apart? Or do libraries providing HTTP services carefully 
document their replay and reordering protections, and application developers 
carefully consider how to deal with replays?

Many websites still say do not hit refresh or you will be charged twice. 0RTT 
enables reordering replay data with interesting effects, and so is distinct 
from doing background updates while changing the UI immediately in that 
requests can happen again adversarially.
>
> Like Kyle mentioned the thing that 0-RTT adds to this is infinite 
> replayability. As mentioned in the other thread we have ways to reduce the 
> impact of infinite replayable data for TLS, making it reasonably replay safe.
>
> Discussions of replayability in the void is impossible. There is no way 
> TLS1.3 is going to know all the use cases for replayability. That is an 
> application layer decision. Thus we should have proposals at the application 
> layer as well to express these properties to the transport layer, and we have 
> one proposal for this which we're going to submit soon to HTTP WG. For 
> example in the case of http, an application should express to the lower 
> layers that the request that it is sending out is retry safe and that it is 
> taking care of it.
>
> Developers are adults too. We can prevent them from shooting themselves in 
> the foot by providing secure OFF by default option, but completely removing 
> the option from them expressing these application properties to the 
> underlying transport layer seems like treating them like children. I would 
> hate to see 0-RTT removed from the spec. This is something we at Facebook are 
> looking forward to using and want to use immediately in browsers once it is 
> available.

Is the "application" HTTP or a website? Many websites got bitten by nginx 
changing how it treated certain retries due to ordering interactions. The 
canonical example is a DELETE and a POST.
>
> Subodh
>
> 
> From: TLS [tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] on behalf of 
> Viktor Dukhovni [ietf-d...@dukhovni.org<mailto:ietf-d...@dukhovni.org>]
> Sent: Monday, March 14, 2016 10:36 AM
> To: tls@ietf.org<mailto:tls@ietf.org>
> Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
>
> > On Mar 13, 2016, at 7:14 AM, Stephen Farrell 
> > mailto:stephen.farr...@cs.tcd.ie>> wrote:
> >
> > So, can people suggest ways in which we can figure out the impact
> > of replayable data across all the many uses of TLS?
>
> For idempotent (more strongly side-effect free) lookup protocols, 0-RTT makes
> good sense.  There is no need for replay protection in the absence of
> side-effects.  Web browsers are not the only use-case for TLS.
>
> Similarly, in SMTP with STARTTLS the client's first data payload is a repeat
> of an EHLO command that was already sent in the clear!  So one might for 
> example
> send the client&#

[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] Tickets and cross protocol attacks

[Subodh Iyengar]

>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.

@David, for #3, I'm referring to fallback in 0-RTT mode. In the normal 
operation case I don't think fallbacks work at all in this mode, so it should 
be fine to reject it to prevent attacks like I mentioned below.

For example let's say a client sends a 0-RTT packet and the server only 
supports TLS1.2, the server will return a server hello with TLS1.2. However 
when it reads data from the session buffer expecting a ClientKeyExchange 
message, it will start getting the 0-RTT data. 

In a case where the server is smart enough to discard all this data (maybe its 
a special TLS1.2  + TLS1.3 server), the behavior when this happens on the 
client side is unspecified, should the client supply the data again in the 
normal TLS stream? should it not resend that data?

It's probably better to reject this fallback when the client has chosen to 
explicitly use a TLS 1.3 feature with 0-RTT in general.

Subodh

From: Martin Thomson [martin.thom...@gmail.com]
Sent: Tuesday, March 29, 2016 6:29 PM
To: David Benjamin
Cc: Subodh Iyengar; tls@ietf.org
Subject: Re: [TLS] Tickets and cross protocol attacks

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] Call for consensus: Removing 0-RTT client auth

[Subodh Iyengar]

If DH 0-RTT client auth is removed, most apps will start using client auth with 
PSK 0-RTT handshakes which is the current state in TLS 1.2 (with tickets) as 
Bill previous mentioned. We've encountered implications of this when using 
TLS1.2 for internal authentication. The tradeoff here is that a server that 
shares a ticket key with another server can masquerade as any client to the 
other server. This is a performance / security tradeoff here, and we solve this 
using partitioning of ticket keys between untrustworthy servers. There are 
several other implications of session tickets that we already deal with for 
this security / performance tradeoff, and this is not the worst one. 

I don't think having some form of 0-RTT client auth is a bad thing since there 
are engineering implications of not providing client auth during 0-RTT. 
A server app is using TLS for cert authentication and doing it's own 
authorization, it might provide certain methods to be accessible without 
authorization, but others with authorization. In a lot of application 
protocols, the client would not know about this aproiri. Not having a form of 
client auth would obviate these from using 0-RTT completely which would be sad.

Since 0-RTT DH is still under discussion, maybe we should revisit 0-RTT DH 
client auth after that is decided?

Subodh Iyengar

From: TLS [tls-boun...@ietf.org] on behalf of Dan Harkins [dhark...@lounge.org]
Sent: Sunday, April 03, 2016 5:43 PM
To: Sean Turner
Cc: tls@ietf.org
Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth

  Hi Sean & Joe,

On Tue, March 29, 2016 5:59 am, Sean Turner wrote:
> 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.

  I don't think it needs to be supported and would be happy if
it was removed. It's a dangerous and flawed feature. My concern
is that if (which I fear is pronounced "when") an exploit is found
it might be easy to remove in a browser update but there's gonna
be some large TLS concentrator vendor that'll have a helluva time
getting its deployed boxes patched and it'll be ugly.

  The rationale for this-- to get an ad to me just that much faster
(an ad, I note, that I sure hope my ad blocking software will prevent
me from seeing), and that the people who want to do this know what
they're doing so it'll all be fine (which is not reassuring in the
least)-- just does not justify the risk.

  regards,

  Dan.


___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=0Wl8UysaIyWxp0Iw_9TKo4jE9Iwn7DnABCdnYWj_2Kk&s=2SuDKxG_YMEaEm1zqgKy4-aHt4NzUB9QVq8SzByaqp8&e=

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

Re: [TLS] Consensus call for keys used in handshake and data messages

[Subodh Iyengar]

With option (2) would the keys end up being independent anyway? I think we 
might need to share the sequence number space between the handshake messages 
and the application data messages to avoid truncation attacks. I might have 
missed this, but was there a proposal to deal with sequence numbers for option 
(2). 

I prefer option (1) since it actually offers some privacy guarantees. 

Subodh

From: TLS [tls-boun...@ietf.org] on behalf of Björn Tackmann 
[btackm...@eng.ucsd.edu]
Sent: Tuesday, June 14, 2016 1:45 PM
To: tls@ietf.org
Subject: Re: [TLS] Consensus call for keys used in handshake and data   messages

Just to be clear: the "+1" I sent earlier meant "I agree with Karthik" -- so it 
means solution (2).

> On Jun 14, 2016, at 1:18 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
>
> Key reuse often ends up causing problems. IMHO a more sound approach is (2). 
> IMHO it isn't prohibitively expensive either.
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
>   Original Message
> From: Björn Tackmann
> Sent: Tuesday, June 14, 2016 05:23
> To: tls@ietf.org
> Subject: Re: [TLS] Consensus call for keys used in handshake and data
> messages
>
> +1
>
>
>> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan 
>>  wrote:
>>
>> I prefer (2)
>>
>>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor  
>>> wrote:
>>>
>>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
 1. Use the same key for handshake and application traffic (as in the
 current draft-13)

 or

 2. Restore a public content type and different keys
>>>
>>> Given this choice, i prefer (1).
>>>
>>> --dkg
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4&e=
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4&e=
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4&e=
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4&e=

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=wAkXyaR6H8OBIwkPYvnVJClJb5pdbQKYE9gf6wApqB4&e=

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

Re: [TLS] Remove EncryptedExtensions from 0-RTT

[Subodh Iyengar]

Was there a compelling reason to not just put the ticket age in the clear in 
the CHLO field as @davidben alluded to before. It seems to make it much simpler 
in general.

With support for multiple tickets the server could issue multiple tickets at 
different times to make time correlation more difficult. The ticket seems to be 
a more definitive identifier of the user than the time.

Subodh

From: TLS [tls-boun...@ietf.org] on behalf of Martin Thomson 
[martin.thom...@gmail.com]
Sent: Thursday, June 23, 2016 1:59 PM
To: David Benjamin
Cc: tls@ietf.org
Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT

On 24 June 2016 at 01:05, David Benjamin  wrote:
> I don't think this matters. Just don't reuse tickets. But, if we cared, per
> the "dumbest possible thing that might work" school of thought, we can
> replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta
> between two ClientHellos, which, precision aside, was already public
> information from the receive time (with ticket as correlator). The timestamp
> of the ticket-minting connection is as secret as before.

That sounds like fine reasoning to me.  XOR or addition are both easy
enough to specify.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=ryrz7HkNEVNbEb9yKsanQ1ZrOyiVdYuv8BDMJOF55s0&s=ftTVBbImgxjUem3AV87OqX3q_RKQKE1SJ7SGePOhWyc&e=

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

Re: [TLS] Issue 472: Remove non-closure warning alerts

[Subodh Iyengar]

+1

Subodh

From: TLS [tls-boun...@ietf.org] on behalf of David Benjamin 
[david...@chromium.org]
Sent: Saturday, July 09, 2016 11:49 AM
To: Salz, Rich; Eric Rescorla; tls@ietf.org
Subject: Re: [TLS] Issue 472: Remove non-closure warning alerts

On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
> If people are in favor of this, I will prepare a PR.

+1

+1

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

Re: [TLS] KeyUpdate and unbounded write obligations

[Subodh Iyengar]

For people that currently use keyupdates or who are planning to use key 
updates, which layer are you planning to trigger a key update? Would the TLS 
implementation itself trigger the update or would the application trigger it? 
For renegotation, I believe it was mostly triggered by the application. 

For the use cases you mentioned Keith, they seem to be specific to application 
triggered key updates, i.e. key updates do not mean anything to the TLS layer 
apart from I got a key update and I must change keys. The fact that other side 
has thrown away it's key is only meaningful to the higher layer protocol. I 
imagine protocols like HTTP would not add these semantics, and these semantics 
would be added to very specific IoT protocols? Would the scope of the auditor 
be defined as a part of that protocol, or does it need to be defined as a part 
of TLS?

If key update is an application triggered mechanism, does the generation 
identifier need to be an integer to be understood by the TLS layer or could it 
also be an opaque identifier sent by the application. It would be much simpler 
not to have to deal with the requirements of consistency at the TLS layer and 
would make the API simpler.

Subodh

From: TLS [tls-boun...@ietf.org] on behalf of Keith Winstein 
[kei...@cs.stanford.edu]
Sent: Friday, August 19, 2016 8:40 PM
To: Stephen Farrell
Cc: Adam Langley; tls@ietf.org
Subject: Re: [TLS] KeyUpdate and unbounded write obligations

On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell
 wrote:
>
> And for me, the dodgiest, by far. The scope for an "auditor"
> (what is that?) actually being an attacker is IMO way too
> high to consider standardising that kind of feature and any
> idea that it'd involve informed consent of someone seems to
> me fictional.

I appreciate the sensitivity of this issue to the WG. My read of your
email is that there's a concern that by standardizing a protocol
mechanism that allows a node to learn when its own KeyUpdate has
happened, the WG would imply approval of features that permit
the bad kind of eavesdropping. Here's why I don't think that's the case:

Our PR is for a piggyback integer field to provide security property
P3: "An implementation can learn that its request to rekey its
outgoing traffic has been read by the other side."

KeyUpdate is an *instruction* to the other side: "please update my key
in a forward-secure manner." We think some implementations will want
to know that the instruction has been carried out. And there's an easy
opportunity to do that here as a piggyback, without any extra protocol
messages.

A node will naturally care more about forward secrecy, and
confirmation of a forward-secure ratcheting event, the more it has
reason to suspect the keys might later be exposed to a third party. In
Berlin, I described three escalating cases: the (1) node going to
sleep, (2) node closing a connection without a mechanism for secure
bidi close, and (3) node that itself intends to release keys to a
read-only auditor after a ratchet is complete.

By "read-only auditor," we mean a curious person or security
researcher who owns an IoT device and wants to know what the heck it
is sending out of their house, where the device doesn't want to allow
its owner to add trusted certificates for an MITM. (This describes
most such devices today.)

Obviously I think it's valuable to make this mechanism available for
IoT device manufacturers. Having talked to several manufacturers, I'm
cautiously optimistic that some would use this. But the WG doesn't
have to take a position on this. These use cases are up to
implementers. There's nothing stopping an implementer today from
releasing session keys, or allowing complete MITM, as is the case in
the browser context with user- or admin-installed root CA
certificates. The TLS WG hasn't opined on these either.

To restate: Property P3 allows a node to learn that its KeyUpdate
instruction has actually happened, which in our view is useful and a
strict benefit over the status quo. It's also orthogonal to the issue
of unbounded write obligations raised in this thread.

-Keith

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=dPWRCHpTfdtxfXYBMZF__UyOa7wszKFnA6criwmMDHI&s=E7sRstn6vNQHPiX3CXAa6BbWSWtMW7VKtN4f3yblZ5U&e=

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

[TLS] New version of delegated credentials draft

[Subodh Iyengar]

Based on the comments during the last TLS WG meeting and the comments on the 
list, we've revised and submitted a new version of delegated credentials  
https://www.ietf.org/id/draft-rescorla-tls-subcerts-01.txt.

This has several salient changes from the previous version:

* We trimmed the fat in the custom structure. The only fields that remain are a 
time and a public key, the necessities.

* We changed the signature algorithm to sign not only the delegated structure, 
but also signs the EE certificate that issued it as well the TLS version that 
was negotiated. This has some advantages over proxy certificates and we 
describe these.


* In the previous draft we described several alternatives. At the last WG 
meeting no one seemed particularly thrilled about using Name constrained certs 
directly, but there was some enthusiasm around either the custom structure or 
proxy certificates. With the changes to signing in this draft, the custom 
structure has some clear advantages, so we cleaned up the draft to remove all 
the alternatives except the custom structure.

* Required the presence of an extension in the EE certificate to allow the use 
of delegated credentials.

* Clarified the behavior of TLS 1.3 and TLS 1.2 clients and servers.

I hope that the cleanup in this draft should make it much easier to discuss 
going forward.

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

Re: [TLS] review comments on draft-rescorla-tls-subcerts-01

[Subodh Iyengar]

Thanks for the comments Ben.


> We mentioned adding a NUL byte separator in the signature on the 
> DelegatedCredential

Yup this is something we noticed during the hackathon interop that would 
definitely be helpful in an implementation and we should change it to have 
that. What we realized when we implemented it was that we ended up representing 
a delegated credential in code as a type of cert with a similar interface for 
verification and it would be useful to reuse the same verification code for TLS 
1.3.


> Do we want to leave the valid SignatureSchemes as all that are defined, or 
> mention the Recommended column in the registry, or narrow things even 
> further?  In other words, should we give some guidance for how to select a 
> scheme to use?

It's restricted to the ones that are supported by the client in TLS 1.3. I 
don't see TLS recommending signature algorithms to use beyond section 4.2.3 
that "rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered.". What 
kind of a recommendation would you like to see. Would love a pull request at 
https://github.com/ekr/tls-subcerts/pulls to get a general idea of what you 
would like to see.


Subodh


From: TLS  on behalf of Kaduk, Ben 
Sent: Tuesday, March 28, 2017 7:12:58 PM
To: tls@ietf.org
Subject: [TLS] review comments on draft-rescorla-tls-subcerts-01

Getting these in email before my printout with red markings gets buried in a 
pile.

We mentioned adding a NUL byte separator in the signature on the 
DelegatedCredential (as well as some other potential tweaks to normalize the 
context strings elsewhere and here).

Do we want to leave the valid SignatureSchemes as all that are defined, or 
mention the Recommended column in the registry, or narrow things even further?  
In other words, should we give some guidance for how to select a scheme to use?

-Ben

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=c2n5STs7L3HaVUDLCexXj_71qQVn5w-ZUJ76hgi1PWs&s=o7UX4TmoWt7yZ-eFOM2nOkq8UJETS_S_szs-YPNjUmo&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

[Subodh Iyengar]

Thanks for your question Brian.

The motivation behind delegated credentials is to create a more reasonable 
deployment model for short lived credentials.

Even without delegated credentials service owners can request short lived 
certificates from their certificate authorities and deploy them to their remote 
servers. Having experience running some reasonably large services and also 
speaking to others who run big services, this presents several challenges:

* Keeping the site up would now involve contacting the CA more frequently than 
before (assuming you're not using OCSP stapling). Even though CAs have good 
infrastructure, the processes for automatic renewal introduces the risk of 
greater errors. Since these errors are across multiple parties these would be 
very hard to diagnose, so people would tend to not have a hard dependency on 
this system. It is much easier to debug and recover from failures if a service 
owner could control the issuance of short lived material with the CA's 
permission.
* Short lived certificates would go into CT logs, and there were several 
concerns raised about the increase in the size of the CT logs.
* A reasonable deployment model would call for private keys to never traverse 
the network. Not everyone should be allowed to contact the CA directly to renew 
the certificate automatically, so deploying short lived certificates would mean 
that you would have to proxy CSRs from the end hosts via some trusted 
infrastructure. This adds some additional moving parts.

This led us to think of whether we could deploy short lived credentials with 
another approach. Once you can deploy short lived credentials we found several 
use cases for these:

* Removing private keys from currently trusted hosts and keeping them in even 
more secure locations. In this way you could increase security by moving keys 
from places they currently exist.
* You could make a security / performance by giving delegated credentials to 
your less trusted locations where you could make the tradeoff that if one of 
these is stolen it's valid only for a very short period of time.

I'm not too familiar with the cloud provider to service owner trust model, but 
your idea of giving the cloud provider a delegated credential instead of a 
longer lived certificate key sounds great.

Delegated credentials bounds time, however if used with other mechanisms you 
can make security protections even more robust. For example you could give your 
cloud provider a delegated credential bound to a certificate with a different 
origin. If you find that something bad has happened you can stop routing 
traffic to that origin as well.

Hopefully this clears things up.

Subodh

From: TLS  on behalf of Brian Sniffen 

Sent: Thursday, March 30, 2017 2:54:29 PM
To: tls@ietf.org
Subject: [TLS] security considerations for draft-rescorla-tls-subcerts

I'm trying to understand the adversary model in which Delegated
Credentials are helpful.  It seems like if you weren't going to sign off
on a cloud service provider getting a certificate before, you *probably*
shouldn't let them have a delegated credential now---but if you were
going to do so, *and* you don't believe revocation works (wise!), now
you can offer a delegated credential and be safer?

That corresponds to an adversary who can compromise a cloud service and
learn the customers' private keys---but can only do so rarely.  Now
instead of having ~ 1 year of use of your certificate, that adversary
has a few days of use of your credential.  But if the cloud service
is regularly breached, you're as bad off as before (but no worse?)

It sounds like the first years of delegated credentials will see them
used in tandem with split systems (Lurk, Akamai and Cloudflare's various 
patented
approaches)---then the primary benefit of delegated credentials is lower
latency for session establishment.

But maybe the idea is to avoid the first circumstance and emphasize that
these are for the second case.  Authors, can you describe what you have
in mind?

Thanks,
Brian

--
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=q03hxbJ9kVRM2fXxXl_8ByxjamwOvDX09DvM_ASPC_o&s=04enApSPuKlAuxTNPBOwVcenAvEku4aZrZ1LgyPQqRk&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

[Subodh Iyengar]

> There is also an alternate world in which the TLS terminators should not have 
> certificates/keys on them but it is okay to give them delegated credentials.  
> Here, one benefit is clear: performance.  But the attacker capabilities 
> against which this is supposed to be useful/acceptable remain unclear.


@Kaduk, Ben I thought I expressed this in the use 
cases, but I might not have been concise enough, so I'll try again.

In our original use case when I say less-trusted I mean a CDN running in a 
different country or a ISPs data center which has a different physical security 
constraints. The less-trusted and trusted hosts do trust each other, i.e. they 
could trust each other with the keys however physical security constraints 
would prevent this.

The threat model here is that since if a less-trusted host having a key is 
compromised for a certain period of time without detection, and an attacker can 
steal private keys during that period. In many situations we are fine with 
giving the TLS terminator a certificate / key, i.e. they actually have a trust 
relationship, however we want a compromise to only give the attacker a limited 
power to use the credential. Revocation is arguably effective, so we would not 
be okay with giving a less trusted host a long term private key. However we'd 
be okay with giving a less-trusted host a short term key.

> My apologies for being blunt, but that text reads like a solution in search 
> of a problem.  That is, what is expected to be achieved by having 
> shorter-lived credentials?  Is there a threat model for which having them 
> brings security advantages, or are there operational concerns, or ... ?


Hopefully the threat model above should answer this question. I thought I was 
clear about the use cases. I think just being able to deploy shorter lived 
credentials to even higher trust areas has an advantage beyond the use cases of 
less trusted locations in case they are compromised.


>  But as currently specified, that low-trust short-lived certificate, if 
> captured, can be used to spoof the operator anywhere else in the world.  Yes, 
> for a shorter time than the long-lived "true" key, but this still seems like 
> a footgun.

@Richard Salz There is no footgun that delegated 
credentials adds beyond what operators can do right now. Operators can go get a 
short lived CA issued certificate and deploy it, however the latter is much 
harder to deploy. See the original email for rationale about this.

>  To me the increase in security weighted with the difficulty of obtaining
such short-lived certificates from a CA probably does not justify the extra
complexity of adding subcerts.

@Simon Friedberger Do you feel that short lived CA certificates are actually 
deployable in large server deployments? I do not see that to be the case. I see 
a security gain here but just being able to deploy short lived credentials to 
not only less trusted locations, but also to more trusted locations as well 
which is another use case that I want to use this for.


Subodh




From: TLS  on behalf of Simon Friedberger 

Sent: Wednesday, April 5, 2017 5:39:17 AM
To: tls@ietf.org
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts

I agree, that's why I only see a security gain if the theft of the
certificate remains undetected.


On 05/04/17 14:35, Salz, Rich wrote:
>>Server operators
>>often want to create short-lived certificates for servers in low-
>>trust zones such as CDNs or remote data centers.
> But as currently specified, that low-trust short-lived certificate, if 
> captured, can be used to spoof the operator anywhere else in the world.  Yes, 
> for a shorter time than the long-lived "true" key, but this still seems like 
> a footgun.
>

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=tBKp_cuV26a4AtN1WOEPpqNTgBQUE4Cg9cqS-Fdw5nI&s=2JwQdlzcb8E6z6hDnhnxLFQZOabIRGTGcJmtBCTj46s&e=
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

[Subodh Iyengar]

> With that goal in mind, wouldn't it help mitigate the threat if
the holder of the longer term credential (the cert subject) were
to include within the signature e.g. an IP address range within
which the delegated credential is allowed to be used?

We thought about this originally, but we discounted this because it breaks when 
http and socks proxies are used. Looking at some data I had a non trivial 
number of requests access our site using proxies. I'm not sure whether there's 
a good method for a client to enforce ip address ranges when a proxy does the 
dns resolution.


Subodh


From: Stephen Farrell 
Sent: Wednesday, April 5, 2017 12:30:31 PM
To: Subodh Iyengar; Simon Friedberger; tls@ietf.org; Richard Salz; Kaduk, Ben
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts


I've no strong opinion for or against this. One question below
though.

On 05/04/17 17:07, Subodh Iyengar wrote:
> The threat model here is that since if a less-trusted host having a
> key is compromised for a certain period of time without detection,
> and an attacker can steal private keys during that period. In many
> situations we are fine with giving the TLS terminator a certificate /
> key, i.e. they actually have a trust relationship, however we want a
> compromise to only give the attacker a limited power to use the
> credential. Revocation is arguably effective, so we would not be okay
> with giving a less trusted host a long term private key. However we'd
> be okay with giving a less-trusted host a short term key.

With that goal in mind, wouldn't it help mitigate the threat if
the holder of the longer term credential (the cert subject) were
to include within the signature e.g. an IP address range within
which the delegated credential is allowed to be used?

Cheers,
S.

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

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

[Subodh Iyengar]

+1 for adoption

@Russ there's some discussion about comparison with proxy certs in the current 
draft.

Subodh


From: TLS  on behalf of Russ Housley 

Sent: Wednesday, April 12, 2017 2:37:28 PM
To: IETF TLS; IETF LURK
Subject: Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

On Wed, Apr 12, 2017 at 12:31 PM, Sean Turner 
mailto:s...@sn3rd.com>> wrote:
All,

At our IETF 98 session, there was support in the room to adopt 
draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list 
so please let the list know whether you support adoption of the draft and are 
willing to review/comment on the draft before 20170429.  If you object to its 
adoption, please let us know why.

Clearly, the WG is going to need to work through the trade-offs between 
short-lived certificates and sub-certs because both seem, to some, to be 
addressing the same problem.

Cheers,

J&S

[0] 
https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

I want to see a solution to this problem, but I think we should look at RFC 
3820, X.509 Proxy Certificate Profile.  I know that this was implemented, but I 
do not know if it is still in use.

Russ

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