Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Yaron Sheffer]

Yes, this is clear to people on this thread. My comment was just about the 
document, which IMO should define its scope more clearly and early on. 

 

Thanks,

    Yaron 

 

From: David Benjamin 
Date: Saturday, 17 December 2022 at 19:25
To: Yaron Sheffer 
Cc: Carrick Bartle , TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

It is, however, mentioned throughout the actual text of the document, assuming 
we're both looking at draft-ietf-tls-deprecate-obsolete-kex-01. I think the 
document describes its current change just fine. I asked only because I wasn't 
sure which the consensus call was about, since that isn't yet reflected in the 
document. (The document just says the group size must be at least 2048 bits in 
TLS 1.2, and then notes that TLS 1.3 satisfies that already. We're now talking 
here about deprecating the DHE ciphers altogether because, without negotiation, 
constraining group size isn't actually viable.)

 

It sounds like this consensus call was indeed just about TLS 1.2, the more 
narrowly-scoped option, so I consider my question satisfied. :-)

 

On Sat, Dec 17, 2022 at 12:03 PM Yaron Sheffer  wrote:

Hi Carrick,

 

While this is clear to the authors, it is not very clear in the document. Even 
though the document only applies to TLS 1.2, TLS 1.2 (the version number) is 
not mentioned in the doc title, in the abstract or in the introduction.

 

Thanks,

Yaron

 

From: TLS  on behalf of Carrick Bartle 

Date: Thursday, 15 December 2022 at 20:15
To: David Benjamin 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi David,

 

My understanding is that we're only discussing deprecating DHE for 1.2. 1.3 is 
out of scope for this document.

 

Carrick

 

 

On Tue, Dec 13, 2022 at 10:06 AM David Benjamin  wrote:

Small clarification question: is this about just FFDHE in TLS 1.2, i.e. the 
TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used in TLS 
1.3?

I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed them 
from Chrome back in 2016 and from BoringSSL not too long afterwards.

 

The DHE construction in TLS 1.2 was flawed in failing to negotiate groups. The 
Logjam attack should not have mattered and instead was very difficult to 
mitigate without just dropping DHE entirely. The lack of negotiation also 
exacerbates the DoS risks with DHE in much the same way. It is also why the 
client text in the current draft ("The group size is at least 2048 bits"), and 
the previous one ("The group is one of the following well-known groups 
described in [RFC7919]: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192") 
are not easily implementable. By the time we've gotten an unsatisfying group 
from the server, it's too late to change parameters. Trying with a new 
connection and different parameters is also problematic because of downgrade 
attacks. A correct scheme would have been defined to only use NamedGroup 
values, and so the server could pick another option if no groups were in common.

 

RFC 7919 should have fixed this, but it too was flawed: it reused the cipher 
suites before, making it impossible to filter out old servers. See these 
discussions:

https://mailarchive.ietf.org/arch/msg/tls/I3hATzFWwkc2GZqt3hB8QX4c-CA/

https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/

https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/

 

Additionally, the shared secret drops leading zeros, which leaks a timing side 
channel as a result. Secrets should be fixed-width. See 
https://raccoon-attack.com/ and https://github.com/tlswg/tls13-spec/pull/462

 

At this point, fixing all this with a protocol change no longer makes sense. 
Any change we make now won't affect existing deployments. Any update that picks 
up the protocol change may as well pick up TLS 1.3 with the ECDH groups. Thus 
the best option is to just deprecate them, so deployments can know this is not 
the direction to go.

 

Of course, some deployments may have different needs. I'm sure there are still 
corners of the world that still need to carry SSL 3.0 with RC4 despite RFC 7465 
and RFC 7568. For instance, during the meeting, we discussed how opportunistic 
encryption needs are sometimes different, which is already generically covered 
by RFC 7435 ("OSS protocols may employ more liberal settings than would be best 
practice [...]"). All that is fine and does not conflict with deprecating. 
These modes do not meet the overall standard expected for TLS modes, so this WG 
should communicate that.

 

I'm somewhere between supportive and ambivalent on the ffdhe* NamedGroup values 
in TLS 1.3. We do not expect to ever implement them in BoringSSL, and their 
performance would be quite a DoS concern if we ever did. But that construction 
is not as deeply flawed as the TLS 1.2 construction.

 

On Tue, Dec 13, 2022 at 9:46 

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Yaron Sheffer]

Hi Carrick,

 

While this is clear to the authors, it is not very clear in the document. Even 
though the document only applies to TLS 1.2, TLS 1.2 (the version number) is 
not mentioned in the doc title, in the abstract or in the introduction.

 

Thanks,

    Yaron

 

From: TLS  on behalf of Carrick Bartle 

Date: Thursday, 15 December 2022 at 20:15
To: David Benjamin 
Cc: TLS List 
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites

 

Hi David,

 

My understanding is that we're only discussing deprecating DHE for 1.2. 1.3 is 
out of scope for this document.

 

Carrick

 

 

On Tue, Dec 13, 2022 at 10:06 AM David Benjamin  wrote:

Small clarification question: is this about just FFDHE in TLS 1.2, i.e. the 
TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used in TLS 
1.3?

I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed them 
from Chrome back in 2016 and from BoringSSL not too long afterwards.

 

The DHE construction in TLS 1.2 was flawed in failing to negotiate groups. The 
Logjam attack should not have mattered and instead was very difficult to 
mitigate without just dropping DHE entirely. The lack of negotiation also 
exacerbates the DoS risks with DHE in much the same way. It is also why the 
client text in the current draft ("The group size is at least 2048 bits"), and 
the previous one ("The group is one of the following well-known groups 
described in [RFC7919]: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192") 
are not easily implementable. By the time we've gotten an unsatisfying group 
from the server, it's too late to change parameters. Trying with a new 
connection and different parameters is also problematic because of downgrade 
attacks. A correct scheme would have been defined to only use NamedGroup 
values, and so the server could pick another option if no groups were in common.

 

RFC 7919 should have fixed this, but it too was flawed: it reused the cipher 
suites before, making it impossible to filter out old servers. See these 
discussions:

https://mailarchive.ietf.org/arch/msg/tls/I3hATzFWwkc2GZqt3hB8QX4c-CA/

https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/

https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/

 

Additionally, the shared secret drops leading zeros, which leaks a timing side 
channel as a result. Secrets should be fixed-width. See 
https://raccoon-attack.com/ and https://github.com/tlswg/tls13-spec/pull/462

 

At this point, fixing all this with a protocol change no longer makes sense. 
Any change we make now won't affect existing deployments. Any update that picks 
up the protocol change may as well pick up TLS 1.3 with the ECDH groups. Thus 
the best option is to just deprecate them, so deployments can know this is not 
the direction to go.

 

Of course, some deployments may have different needs. I'm sure there are still 
corners of the world that still need to carry SSL 3.0 with RC4 despite RFC 7465 
and RFC 7568. For instance, during the meeting, we discussed how opportunistic 
encryption needs are sometimes different, which is already generically covered 
by RFC 7435 ("OSS protocols may employ more liberal settings than would be best 
practice [...]"). All that is fine and does not conflict with deprecating. 
These modes do not meet the overall standard expected for TLS modes, so this WG 
should communicate that.

 

I'm somewhere between supportive and ambivalent on the ffdhe* NamedGroup values 
in TLS 1.3. We do not expect to ever implement them in BoringSSL, and their 
performance would be quite a DoS concern if we ever did. But that construction 
is not as deeply flawed as the TLS 1.2 construction.

 

On Tue, Dec 13, 2022 at 9:46 AM Sean Turner  wrote:

During the tls@IETF 115 session topic covering 
draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there was 
support to deprecate all FFDHE cipher suites including well-known groups. This 
message starts the process to judge whether there is consensus to deprecate all 
FFDHE cipher suites including those well-known groups. Please indicate whether 
you do or do not support deprecation of FFDHE cipher suites by 2359UTC on 6 
January 2023. If do not support deprecation, please indicate why.

NOTE: We had an earlier consensus call on this topic when adopting 
draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. If 
necessary, we will start consensus calls on other issues in separate threads.

Cheers,
Chris, Joe, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

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

___
TLS mailing list

Re: [TLS] [Uta] Question regarding RFC 8446

[Yaron Sheffer]

Hi Paul,

I'm actually not sure this is a good idea, and not because we are at the RFC 
Editor.

TLS has intentionally kept this aspect out of scope basically forever. The 
following text appears in TLS 1.0 (Jan. 1999) and still appears unchanged in 
TLS 1.3:

"No part of this standard should be taken to dictate the manner in which a 
usage profile for TLS manages its data transport, including when connections 
are opened or closed."

Given we left this behavior unspecified, it is no wonder that people have 
differing implementations. I'm not sure it is appropriate for UTA to make this 
decision for the whole industry and hundreds of protocols that are layered on 
top of TLS.

Thanks,
Yaron

On 08/11/2022, 10:05, "Uta on behalf of Paul Wouters"  wrote:

On Mon, 7 Nov 2022, Eric Rescorla wrote:

> Subject: Re: [TLS] Question regarding RFC 8446
> 
> Hi David,
> 
> This question seems a bit out of scope for TLS, which is kind of 
indifferent to the transport interaction.
> 
> Perhaps it might make sense to be in UTA, though unfortunately, RFC 
7525-bis is in the editor queue now...

I just talked to my fellow AD, and we are okay with a one line/paragraph
addition to 7525-bis if the document authors and UTA chairs are okay
with this as well. It seems a real interop issue that would be good to
nail down.

Paul

> -Ekr
> 
> 
> On Mon, Nov 7, 2022 at 1:37 AM David Barr  wrote:
>   How can I make suggestions for the TLS specifications? I'm having a 
problem that could be clarified by a change to the spec.
> This is the sentence that causes problems for me: "how to initiate TLS 
handshaking and how to interpret the authentication certificates exchanged
> are left to the judgment of the designers and implementors of protocols 
that run on top of TLS".
> 
> I have two vendors that have implemented software that layers the HL7 
protocol on top of TLS. The Epic implementation does not perform a handshake
> until it has data to send. This could be hours after the TCP connection 
is established. There is no other TCP communication prior to the handshake
> (e.g. a STARTTLS command). The Infor Cloverleaf implementation times out 
waiting for a handshake, and the software becomes unresponsive while this
> is happening.
> 
> It would be helpful if the TLS spec added something like this:
>
>   If protocols that are layered on top of TLS use implicit encryption 
(relying on a port number rather than an explicit command that is
>   issued before the handshake), then the handshake should begin 
immediately after the TCP/IP socket connection is established.
> 
> I have no idea how suggestions like this make it into the spec, so if I 
need to suggest this somewhere else, please let me know.
> 
> David Barr
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
>

___
Uta mailing list
u...@ietf.org
https://www.ietf.org/mailman/listinfo/uta


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

Re: [TLS] OCSP in RFC7525bis - summary of the discussion

[Yaron Sheffer]

Thank you all for the lively and far reaching discussion on revocation and 
OCSP. Let me summarize how the authors of RFC7525-bis read the consensus - UTA 
WG chairs, please chime in if you disagree.
 
There seems to be consensus that applications should be able to handle 
certificate revocation. There is (weaker) consensus that OCSP is the preferred 
solution, and no consensus at all about the technical details. For example, 
clients failing hard is not in consensus - but neither is the opposite.
 
So our plan moving forward is to essentially keep the new text on OCSP [1] and 
add a reference to RFC 7633 (the certificate must-staple extension). But only 
as a MAY. In addition, we will add a MUST requirement to perform (some kind of) 
revocation checking.
 
If you have not read the Pull Request, please note that it's a significant 
change over RFC7525, e.g. 6961 is no longer recommended.
 
There was some back and forth about DNSSEC, short-lived certs, CAA and CT as 
mitigating controls, but we don't see them as clearly in scope of the document.
 
Thanks,
Yaron
 
[1] https://github.com/yaronf/I-D/pull/279/files

---

From: Yaron Sheffer 
Date: Wednesday, January 19, 2022 at 16:57
To: "u...@ietf.org" , "tls@ietf.org" 
Subject: OCSP in RFC7525bis

Hi,

RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use 
OCSP and OCSP stapling. We are changing these recommendations [2] in view of 
OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail 
if they don’t get an OCSP response within the handshake, i.e. they just ignore 
the problem. As far as we understand, this makes OCSP stapling completely 
ineffective for what it’s trying to solve.

So for the new BCP, we have three options:
- Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also 
TLS 1.2 implementations) to fail the handshake if the OCSP response is missing 
or invalid. (As far as we can tell, RFC 8446 is silent on this.)
- Remove the whole discussion of OCSP, saying that in its current form it’s not 
adding value.
- Maintain the status quo, where many people implement OCSP on the server side, 
but clients rarely benefit.

We would be grateful for feedback based on implementation experience. In 
particular if you have quantitative data on the use or quality of OCSP that’s 
more recent than Chung18 [3], that would be very useful.

Thanks,
    Peter, Thomas and Yaron

PS: apologies for cross-posting.


[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] https://github.com/yaronf/I-D/pull/279/files
[3] https://cbw.sh/static/pdf/chung-imc18.pdf



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

Re: [TLS] OCSP in RFC7525bis

[Yaron Sheffer]

Hi Hannes, This is not about my personal beliefs. RFC 7525 looks at certificate revocation in the context of TLS (and not only TLS for Web use but the broader ecosystem) and recommends OCSP and OCSP Stapling as the best available techniques to enable effective certificate revocation, but with caveats. It’s been more than 6 years since the RFC was published, and we are reviewing our recommendations, which may or may not still be valid. Thanks,    Yaron From: Hannes Tschofenig Date: Thursday, January 20, 2022 at 12:00To: Yaron Sheffer , u...@ietf.org , tls@ietf.org Subject: RE: OCSP in RFC7525bisHi Yaron,  Where do you believe OCSP will be a good fit and why?  CiaoHannes From: TLS  On Behalf Of Yaron ShefferSent: Wednesday, January 19, 2022 3:57 PMTo: u...@ietf.org; tls@ietf.orgSubject: [TLS] OCSP in RFC7525bis Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if they don’t get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it’s trying to solve. So for the new BCP, we have three options:1.  Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)2.  Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.3.  Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit. We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be very useful. Thanks,    Peter, Thomas and Yaron PS: apologies for cross-posting.  [1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5[2] https://github.com/yaronf/I-D/pull/279/files[3] https://cbw.sh/static/pdf/chung-imc18.pdf IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] OCSP in RFC7525bis

[Yaron Sheffer]

Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if they don’t get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it’s trying to solve. So for the new BCP, we have three options:Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit. We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be very useful. Thanks,    Peter, Thomas and Yaron PS: apologies for cross-posting.  [1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5[2] https://github.com/yaronf/I-D/pull/279/files[3] https://cbw.sh/static/pdf/chung-imc18.pdf 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: supported_versions in TLS 1.2

[Yaron Sheffer]

On 11/29/21, 22:40, "Peter Saint-Andre"  wrote:On 11/29/21 11:29 AM, Andrei Popov wrote:> Perhaps I missed some part of this thread, but it’s still not clear to > me what would be the purpose of adding supported_versions extension to a > TLS 1.2 implementation? What problem(s) would that solve? Based in part on discussion here, we (the authors of 6125bis) concluded  Typo: should be 7525bis (the TLS BCP). [1] that we don't need to recommend adding the supported_versions extension to TLS 1.2-only implementations. If folks find that decision problematic, do let us know. Peter [1] https://github.com/yaronf/I-D/issues/253 ___TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

[Yaron Sheffer]

I fully agree. Thank you Ben!

On 4/6/21, 21:43, "Benjamin Kaduk"  wrote:

Hi Yaron,

Thanks for the (multiple!) reviews.

My understanding is that the intention is not to allow "server_name" in all
CertificateRequests but only specifically in the ClientCertificateRequest
case.  I think it can be helpful to notate that with a "CR" in the "TLS
1.3" column of the registry but we would need some further clarification as
to what that notation actually means.  I left some suggestions for how to
do that in my ballot position, but to summarize: a "comment" column in the
registry would be great for this, and failing that a note in the IANA
Considerations of this document to clarify what is and is not being
registered would probably work as well.

Thanks again for highlighting this point,

Ben

    On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker 
wrote:
> Reviewer: Yaron Sheffer
> Review result: Has Issues
> 
> After a bit of back and forth over my *two* previous SecDir requests, I'm
> afraid that my original comment has not yet been fully addressed. The IANA
> considerations section (Sec. 8.1) adds server_name as a possible 
extension for
> CertificateRequest. This would be a non-backward compatible change to TLS.
> 
> IMO what we needed to do is both to clarify the allowed extensions for 
what
> Nick called "the CR-like structure" (almost done in Sec. 4, though the 
last
> sentence should by changed to include CertificateRequest) and undo the 
change
> to the TLS ExtensionType registry (not done, would require to remove Sec. 
8.1).
> 
> * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, 
and in
> both cases is mangled.
> 
> Old:
> 
> The application layer protocol used to send the authenticator request 
SHOULD
> use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as 
its
> as its underlying transport to keep the request confidential.
> 
> New:
> 
> The application layer protocol used to send the authenticator request 
SHOULD
> use a secure *channel* with equivalent security to TLS, such as QUIC
> [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
> confidential.
> 
> 


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

[TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

[Yaron Sheffer via Datatracker]

Reviewer: Yaron Sheffer
Review result: Has Issues

After a bit of back and forth over my *two* previous SecDir requests, I'm
afraid that my original comment has not yet been fully addressed. The IANA
considerations section (Sec. 8.1) adds server_name as a possible extension for
CertificateRequest. This would be a non-backward compatible change to TLS.

IMO what we needed to do is both to clarify the allowed extensions for what
Nick called "the CR-like structure" (almost done in Sec. 4, though the last
sentence should by changed to include CertificateRequest) and undo the change
to the TLS ExtensionType registry (not done, would require to remove Sec. 8.1).

* Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, and in
both cases is mangled.

Old:

The application layer protocol used to send the authenticator request SHOULD
use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its
as its underlying transport to keep the request confidential.

New:

The application layer protocol used to send the authenticator request SHOULD
use a secure *channel* with equivalent security to TLS, such as QUIC
[QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
confidential.


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

[TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate

[Yaron Sheffer]

Hi,

We are now revising RFC 7525 for the new world, and in general we are following 
this draft. So, MUST NOT negotiate TLS 1.0 and 1.1. This brought up the 
question of SCSV, which was new when RFC 7525 was published but has since been 
widely implemented/deployed.

I think marking the “oldversions” draft as “obsoletes RFC 7507 (SCSV)” is not 
great from an ecosystem point of view. People will interpret it as “no need to 
implement SCSV in new code, no need to expose it as a configuration option in 
existing code”. And we know that some admins will continue to allow downgrade 
to TLS 1.0/1.1 no matter what we tell them. IMO we should protect these people 
from downgrade attacks, even if we disagree with their policy.

So I would call for a more nuanced wording re: SCSV, something like 
(paraphrasing EKR):

In the world where the only valid values of TLS are 1.2 and 1.3+, the TLS 1.3 
fallback mechanism should render the SCSV unnecessary. However for existing 
client and server implementations that still include support for earlier TLS 
versions, SCSV should continue to be supported.

Thanks,
Yaron


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

[TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-13

[Yaron Sheffer via Datatracker]

Reviewer: Yaron Sheffer
Review result: Has Nits

It's been a long time...

My mail here [1] mentions two remaining open issues: a mention of QUIC and the
code point.

The first (small) issue seems to have been forgotten.

I believe the second issue has been addressed by the WG, with the introduction
of a new message type.

[1] https://mailarchive.ietf.org/arch/msg/secdir/n54wuiSwCx9VqgSrrWvX_9FCoW0/


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

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

[Yaron Sheffer]

Hi Nick,

 

Apologies for not responding on time.

 

I may be missing some follow-on discussions, but:

 
Ben suggested that we mention that QUIC is also an option, even if 
informatively, in addition to the “SHOULD use TLS” statement.
I think we left my question re: back-fitting this protocol into the IANA TLS 
registry open. Quoting: 
 

YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I 
think it's a really bad idea. Better to hack special support to existing 
libraries, allowing this specific extension for this special case, than to 
change the base protocol. Otherwise, this document should UPDATE 8446.

 

NS: This is a good point and one that we struggled a bit with during design.. 
We needed to allow SNI in the CertificateRequest message because it can be 
client-generated in this context. I'd be ok with creating a different extension 
for this, but it's rather elegant to re-use it in this context. *I'd like to 
hear some opinions from the working group* on this point

 

BK: Or, since extension codepoints are cheap, just use a new codepoint.

 

Thanks,

    Yaron

 

From: Nick Sullivan 
Date: Monday, November 4, 2019 at 04:49
To: Yaron Sheffer 
Cc: , , 
, "" 
Subject: Re: Secdir last call review of draft-ietf-tls-exported-authenticator-09

 

Following up,

 

Yaron, do the responses by myself and Benjamin along with the does the 
following PR sufficiently address your comments/concerns?

 

https://github.com/tlswg/tls-exported-authenticator/pull/52

 

On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan  wrote:

Hi Yaron,

 

Thank you for your thorough review. My answers will be inline, and I'll 
incorporate some of Ben's replies if necessary. Here's a PR with proposed 
changes in response to your comments:

https://github.com/tlswg/tls-exported-authenticator/pull/52

 

On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker 
 wrote:

Reviewer: Yaron Sheffer
Review result: Has Issues

The document is generally clear in both its motivation and the proposed
solution.

I think it's playing a bit too liberal with TLS 1.3, in sort-of but not quite
deprecating renegotiation, and in changing the IANA registry in a way that
actually changes the protocol. Details below.

Other comments:

* Abstract: please reword to make it clear that it's the proof (not the cert)
that is portable.

 

Proposed text here:

This document describes a mechanism in Transport Layer Security (TLS) for peers 
to
provide a proof of ownership of a certificate.  This proof can be exported
by one peer, transmitted out-of-band to the other peer, and verified by the 
receiving peer.

 

* Introduction: TLS 1.3 post-handshake auth "has the
disadvantage of requiring additional state to be stored as part of the TLS
state machine." Why is that an issue is practice, assuming this feature is
already supported by TLS libraries? Also, are we in effect deprecating this TLS
1.3 feature because of the security issue of the mismatched record boundaries?

 

My understanding is that post-handshake authentication as defined in the TLS 
1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some 
implementors would prefer to use exported authenticators.

 

* "For simplicity, the mechanisms... require", maybe a normative REQUIRE?

I'm fine with this.

 

* Authenticator Request: please clarify that we use the TLS 1.3 format even when
running on TLS 1.2.

 Updated, though it might be a bit unnecessary.

 

* Also, I suggest to change "is not encrypted with a
handshake key" which is too specific to "is sent unencrypted within the normal
TLS-protected data".

This specific text is meant to differentiate the wire format of this message 
from that of the CertificateRequest message, which is encrypted with the 
handshake key. The specificity is warranted.

 

* Before diving into the detailed messages in Sec. 3, it
would be nice to include a quick overview of the message sequence.

There are two message types and three potential sequences. I've added a short 
overview.

 

* Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can work otherwise anyway.

As Ben noted, this could be any secure channel with equivalent security to TLS, 
such as QUIC. We shouldn't forbid other secure out-of-band mechanisms.

 

* "This message reuses the structure to the CertificateRequest message" -
repeats the preceding paragraph.

Fixed

 

* Sec. 4: again, SHOULD use TLS -> MUST.

Again, I don't see the need for a MUST here.

 

* Is
there a requirement for all protocol messages to be sent over a single TLS
connection? If so, please mention it. Certainly this is true for the
Authenticator message that must be sent over a single connection and cannot be
multiplexed by the high-level protocol. I think this protocol actually assumes
"nice" transport properties (no message reorder, reliability) that also require
a singl

[TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

[Yaron Sheffer via Datatracker]

Reviewer: Yaron Sheffer
Review result: Has Issues

The document is generally clear in both its motivation and the proposed
solution.

I think it's playing a bit too liberal with TLS 1.3, in sort-of but not quite
deprecating renegotiation, and in changing the IANA registry in a way that
actually changes the protocol. Details below.

Other comments:

* Abstract: please reword to make it clear that it's the proof (not the cert)
that is portable. * Introduction: TLS 1.3 post-handshake auth "has the
disadvantage of requiring additional state to be stored as part of the TLS
state machine." Why is that an issue is practice, assuming this feature is
already supported by TLS libraries? Also, are we in effect deprecating this TLS
1.3 feature because of the security issue of the mismatched record boundaries?
* "For simplicity, the mechanisms... require", maybe a normative REQUIRE? *
Authenticator Request: please clarify that we use the TLS 1.3 format even when
running on TLS 1.2. * Also, I suggest to change "is not encrypted with a
handshake key" which is too specific to "is sent unencrypted within the normal
TLS-protected data". * Before diving into the detailed messages in Sec. 3, it
would be nice to include a quick overview of the message sequence. * Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can work otherwise anyway.
* "This message reuses the structure to the CertificateRequest message" -
repeats the preceding paragraph. * Sec. 4: again, SHOULD use TLS -> MUST. * Is
there a requirement for all protocol messages to be sent over a single TLS
connection? If so, please mention it. Certainly this is true for the
Authenticator message that must be sent over a single connection and cannot be
multiplexed by the high-level protocol. I think this protocol actually assumes
"nice" transport properties (no message reorder, reliability) that also require
a single, clean TLS connection. * Why no authenticator request for servers?
Don't we care about replay? OTOH if the client wants to detect replays, it
would need to keep state on received authenticators, which would be very messy.
* 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. * The
discussion of Extended Master Secret only applies to TLS 1.2 - please clarify
that, plus I suggest to reword this paragraph which I find hard to parse. *
4.2: "the extensions are chosen from the TLS handshake." - What does it mean
exactly, and how does an application even know which extensions were used at
the TLS layer? Reading further, we mention "ClientHello extensions." Maybe the
authenticator should also include a ClientHello message to indicate supported
extensions. Assuming we can peek into ClientHello contradicts the hopeful "even
if it is possible to implement it at the application layer" in Sec. 6. * 4.2.1:
the first sentence of the section is incomplete. * Can I use TLS 1.3-specific
extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a
situation where a certificate is acceptable for TLS 1.3 connections but not for
TLS 1.2 connections? * "using a value derived from the connection secrets" - I
think we should recommend a specific construction here to ensure people do it
securely. * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If
so, please say so. * 4.2.4: "a constant-time comparison" - why is it actually
required, what is the threat? An attacker can do very little because each
authenticator being sent is different. * 5: please say explicitly which
messages are used in this case to construct the authenticator. * 6.1: the
"MUST" is strange in a section that's only supposed to be informative. Also,
the library may provide this extension (and possibly others) without requiring
it as input. * 6.4: "The API MUST return a failure if the
certificate_request_context of the authenticator was used in a previously
validated authenticator." Are we requiring the library to keep previous
contexts for replay protection? If so, please make it explicit. *  7.1: this is
changing TLS 1.3 by allowing this extension in Cert Request! I think it's a
really bad idea. Better to hack special support to existing libraries, allowing
this specific extension for this special case, than to change the base
protocol. Otherwise, this document should UPDATE 8446. * 8: I think the
Security Considerations is the right place to talk about interaction between
this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMMEND
not to do it. Or else explain the use cases where renegotiation is still useful
if there are any.

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

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

[Yaron Sheffer]

I strongly support this work.

Also, having made this mistake myself in the past: please make sure that 
we have one fully specified PAKE in this document, and not only a 
generic envelope. This will ensure that TLS libraries have at least one 
working, and interoperable, PAKE,


Thanks,
Yaron

On 19/07/18 10:10, Tim Hollebeek wrote:
Unfortunately, I haven’t had time to review the document, but +1 for 
interesting problem, and +1 for anything Richard writes as a good 
starting point, even if I haven’t read it.


-Tim

*From:* TLS  *On Behalf Of *Hugo Krawczyk
*Sent:* Wednesday, July 18, 2018 7:13 PM
*To:* Richard Barnes 
*Cc:*  
*Subject:* Re: [TLS] Fwd: New Version Notification for 
draft-barnes-tls-pake-04.txt


+1 for this work.

If you are one of those that think, as I did 20 years ago, that password 
authentication is dying and practical replacements are just around the 
corner, do not support this document. Otherwise, please do.


Asymmetric or augmented PAKE (aPAKE) protocols provide secure password 
authentication in the common client-server case (where the server stores 
a one-way mapping of the password) without relying on PKI - except 
during user/password registration. Passwords remain secure regardless of 
which middleboxes or endpoints spy into your decrypted TLS streams.  The 
server never sees the password, not even during password registration.


To see real deployment of such protocols, they need to be integrated 
with TLS which is what Barnes's draft facilitates. Not only this improve 
significantly the protection of passwords and password authentication, 
but aPAKE protocols also provide an hedge against PKI failures by 
enabling mutual client-server authentication without relying on regular 
server certificates.


Hugo

On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes > wrote:


Hey TLS WG,

In response to some of the list discussion since the last IETF, Owen
and I revised our TLS PAKE draft.  In the current version, instead
of binding to a single PAKE (SPAKE2+), it defines a general
container that can carry messages for any PAKE that has the right
shape.  And we think that "right shape" covers several current
PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, .

The chairs have graciously allotted us 5min on the agenda for
Thursday, where I'd like to ask for the WG to adopt the document. 
So please speak up if you think this is an interesting problem for

the TLS WG to work on, and if you think the approach in this
document is a good starting point.  Happy for comments here or at
the microphone on Thursday!

Thanks,

--Richard

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes mailto:r...@ipv.sx>>, Owen Friel
mailto:ofr...@cisco.com>>




A new version of I-D, draft-barnes-tls-pake-04.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-barnes-tls-pake
Revision:       04
Title:          Usage of PAKE with TLS 1.3
Document date:  2018-07-16
Group:          Individual Submission
Pages:          11
URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt
Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04

Abstract:
    The pre-shared key mechanism available in TLS 1.3 is not
suitable for
    usage with low-entropy keys, such as passwords entered by users.
    This document describes an extension that enables the use of
    password-authenticated key exchange protocols with TLS 1.3.




Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org
.

The IETF Secretariat


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



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



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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Yaron Sheffer]

I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)


It isn't a question of shame but it is just a bit too much information
to provide a potential adversary.  That is, to say that Stock Exchange XYZ
has n% of TLS1.0 clients provides a potential attacker too much
information.


Not sure I agree there tbh. If they're externally visible
services, then it's public already. If they're not, and the
attacker is inside the n/w, then the bad actor can find it
out then. But I do understand organisations being shy about
such things.



Having gone through this exercise recently, I agree with Nalini on why 
people would not want to report openly.


For a typical enterprise, 10% TLS 1.0 in the internal network could well 
mean that 10% of your servers are Java boxes that have not been updated 
in the last two years (and so are riddled with vulnerabilities that are 
much more severe than the old TLS version). Absolutely a good reason to 
be ashamed :-) and certainly not information that you'd want to share 
openly.


Thanks,
Yaron

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

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

[Yaron Sheffer]

On 18/07/17 18:34, Watson Ladd wrote:


I understand the logics but, since LURK boxes don’t scale, the
cost to cover your entire footprint for the sporadic cases when
the CA is down might be a bit prohibitive.


CA reliability is not good.


From my own experience, I agree that CA reliability is "not good". 
However if I'm using short-term certs with say, a 7 day validity, and 
(per draft-ietf-acme-star) the next certificate is issued halfway 
through this period, it means that the CA has to to be unavailable for 
all of 3.5 days for the failure to affect the delegated site. That's a 
lot, even for a CA.


On the other hand the LURK signing box (though managed by the same 
organization, which is a clear benefit) needs to be available at the 
same level of the delegated site - 99.99% of the time or whatever your 
standard is.


Thanks,
Yaron

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

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Yaron Sheffer]

Hi Stephen,

Like you, I am very unhappy with this draft, and would not support its 
adoption as a WG draft. However I think that open discussion is in 
general good, and that the best venue for discussion of this draft is 
this mailing list. Even if some of this discussion devolves into generic 
"are we pro or against wiretapping" questions.


I don't think this is a significant distraction that could derail 
(D)TLS, moreover, you will recall that in Chicago several new drafts 
were adopted to the working group. So the WG does feel that TLS is in 
good enough shape that we can spend some bandwidth on other things.


Thanks,

Yaron


On 08/07/17 12:17, Stephen Farrell wrote:

Sean/Joe,

This is a request that you, as chairs, shut down the distracting
wiretapping discussion, at least until DTLS1.3 is done.

I have planned to spend time reading draft 21 and DTLS, but that
won't happen if we keep having to fight off the latest attempts
to break TLS. I'd not be surprised if I weren't the only one
finding that distraction an irritating waste of time. Finishing
TLS1.3 and getting DTLS1.3 on the way surely needs to not be
constantly de-railed by these attempts to break TLS.

Therefore I'd ask that you declare this discussion closed for at
least that long (i.e until DTLS1.3 is done).

I'd also ask that you not allocate agenda time for wiretapping
in Prague.

Thanks,
S.



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


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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

I’m not even sure what my position is on this. Specifying the use of a
context here goes against the recommendation in the CFRG draft:

  Contexts SHOULD NOT be used opportunistically, as that kind of use
  is very error-prone.  If contexts are used, one SHOULD require all
  signature schemes available for use in that purpose support
  contexts.

If someone knows why this recommendation was made, that would be great.


Basically, then those other methods would be a weak point for attack.



But we are trying to migrate away from the old methods, into the new 
methods. The fewer servers use the old methods, the better off we are, 
right? So we expect the attack surface to gradually be reduced over the 
coming years.





Then there's the serious deployment problems with contexts, as those
don't fit into any standard notion of signature various libraries have.



These are new algorithms that are still not widely deployed. The fact 
that several open source libraries (still) don't support a certain 
function parameter is not a very strong reason not to require it.


Thanks,
Yaron

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

So the key schedule changed and therefore we think cross-version attacks 
are impossible. Have we also analyzed other protocols to ensure that 
cross protocol attacks, e.g. with SSH or IPsec, are out of the question?


Put differently, algorithm designers gave us a cheap, easy to use tool 
to avoid a class of potential attacks. Why are we insisting on not using it?


Thanks,
Yaron

On 20/11/16 17:33, Salz, Rich wrote:

For those who missed CURDLE, could you please briefly explain why we don't
need signature context in non-TLS areas.


The one place we were concerned about attacks was in pre-hash signatures, and 
we made those a MUST NOT.  And yes, your'e right, it's not relevant to TLS.


So why are we now saying that contexts are not needed even for TLS?


I think because the key schedule changed.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz




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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

Hi Rich,

I am confused by your response.

For those who missed CURDLE, could you please briefly explain why we 
don't need signature context in non-TLS areas.


And even if this is the case, the current thread is about TLS! So why 
are we now saying that contexts are not needed even for TLS?


Thanks,
Yaron

On 20/11/16 13:21, Salz, Rich wrote:

In CURDLE this week, we had consensus (to be confirmed on the list, of course) 
that
Signature contexts were created in the TLS arena, we all thought we 
needed them in other areas, and we don't, therefore all CURDLE documents for 
those other areas will specify a zero-length context.

FWIW.

I agree with Yoav's message, for the reasons he states.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz



-Original Message-
From: Sean Turner [mailto:s...@sn3rd.com]
Sent: Friday, November 18, 2016 6:56 PM
To: 
Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis

All,

This is a working group last call for the “4492bis to Standards Track" draft
available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please
review the document and send your comments to the list by 9 December
2016.

Note that we are particularly interesting in the issue Yoav raises in the
following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

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

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



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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

I have not read the document in full (but still noticed a typo in the 
paragraph we're discussing), so I will not comment on its readiness.


Regarding signature context: I don't understand the CFRG recommendation 
that Yoav is citing. IMO we should include a context string wherever we 
can, to reduce the number of possible cross-protocol (or cross-signature 
scheme) attacks. As far as I know context strings do not cost anything 
and can only improve the protocol's security.


Maybe one day we will only have signatures deployed that support 
context, but if we don't add the context string now we will never get 
there. We are not going to revise TLS just to add a context string to EdDSA.


Thanks,
Yaron

On 19/11/16 08:55, Sean Turner wrote:

All,

This is a working group last call for the “4492bis to Standards Track" draft 
available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please 
review the document and send your comments to the list by 9 December 2016.

Note that we are particularly interesting in the issue Yoav raises in the 
following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

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



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

[TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-03.txt

[Yaron Sheffer]

Daniel and I just submitted a new version of this draft. Other than 
numerous editorial improvements and clarifications, the main changes are 
to the cryptographic operations, to bring them in-line with the latest 
version of TLS 1.3.


Thanks,
Yaron

 Forwarded Message 
Subject: New Version Notification for 
draft-sheffer-tls-pinning-ticket-03.txt

Date: Tue, 04 Oct 2016 03:00:10 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer <yaronf.i...@gmail.com>, Daniel Migault 
<daniel.miga...@ericsson.com>



A new version of I-D, draft-sheffer-tls-pinning-ticket-03.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-tls-pinning-ticket
Revision:   03
Title:  TLS Server Identity Pinning with Tickets
Document date:  2016-10-04
Group:  Individual Submission
Pages:  23
URL: 
https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/
Htmlized: 
https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-03
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-03


Abstract:
   Misissued public-key certificates can prevent TLS clients from
   appropriately authenticating the TLS server.  Several alternatives
   have been proposed to detect this situation and prevent a client from
   establishing a TLS session with a TLS end point authenticated with an
   illegitimate public-key certificate, but none is currently in wide
   use.

   This document proposes to extend TLS with opaque pinning tickets as a
   way to pin the server's identity.  During an initial TLS session, the
   server provides an original encrypted pinning ticket.  In subsequent
   TLS session establishment, upon receipt of the pinning ticket, the
   server proves its ability to decrypt the pinning ticket and thus the
   ownership if the pinning protection key.  The client can now safely
   conclude that the TLS session is established with the same TLS server
   as the original TLS session.  One of the important properties of this
   proposal is that no manual management actions are required.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [TLS] Industry Concerns about TLS 1.3

[Yaron Sheffer]

What exactly is the problem you are concerned with? As I've pointed
out previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting
proxy. What information does this not get you that you need on the
network?


For enterprises using Content Delivery Networks, the TLS session from
the browser ends at the edge server in the Content Delivery Network.
The session that the enterprise sees is completely different:
different IP's and ports, different TLS session, different
application layer content because of caching, different network
behavior (like packet drops and retransmissions).  If some
infrastructure component in the data center is causing a problem, a
trace on the browser side is blind to that.  An additional problem is
that Microsoft does not allow logging of ephemeral keys in their
browser.


[...]

From the time a packet enters a data center, it is travelling
through routers, switches, firewalls, load balancers, web servers,
app servers, middleware servers, and possibly hitting a mainframe,
all TLS encrypted for many enterprises.  Frequently, source and
destination IP's are NAT'ed multiple times, so there is no visible
relationship between the packet that enters the data center and the
same call at deeper layers of the infrastructure.  Any one of these
infrastructure nodes could be the cause of a problem.  The way to
isolate the fault domain of a problem is to take a packet trace at
each tier of the application infrastructure and look at the
application layer data in a decrypted trace in order to find the
transaction that is failing.




You are implicitly suggesting to remove perfect-forward-secrecy as soon 
as a TLS flow is created by the CDN. However these packets will still be 
traveling over the public Internet and/or "private" (leased, not really 
private) MPLS VPNs, where we KNOW that government agencies are 
eavesdropping and recording network flows to keep for years ahead. In 
other words, even when the TLS flow enters "your" network, you and your 
customer are still at risk from pervasive monitoring.


Thanks,
Yaron

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

[TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-02.txt

[Yaron Sheffer]

Hi everyone,

This draft extends TLS 1.3 to provide pinning of the TLS server using a
stateless ticket. This is similar to public-key pinning but not quite,
and our goal was to overcome the deployment issues that prevent
widespread deployment of HPKP.

Version -02 of the draft incorporates learnings from my proof-of-concept
implementation at https://github.com/yaronf/mint. Thanks to the authors
on the Mint TLS 1.3 implementation from which my code was forked.

Best,
Yaron

 Forwarded Message 
Subject: New Version Notification for
draft-sheffer-tls-pinning-ticket-02.txt
Date: Fri, 08 Jul 2016 06:42:25 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer <yaronf.i...@gmail.com>


A new version of I-D, draft-sheffer-tls-pinning-ticket-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-tls-pinning-ticket
Revision:   02
Title:  TLS Server Identity Pinning with Tickets
Document date:  2016-07-08
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-02.txt
Status:
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/
Htmlized:
https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-02

Abstract:
   Fake public-key certificates are an ongoing problem for users of TLS.
   Several solutions have been proposed, but none is currently in wide
   use.  This document proposes to extend TLS with opaque tickets,
   similar to those being used for TLS session resumption, as a way to
   pin the server's identity.  That is, to ensure the client that it is
   connecting to the right server even in the presence of corrupt
   certificate authorities and fake certificates.  The main advantage of
   this solution is that no manual management actions are required.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

Re: [TLS] Downgrade protection, fallbacks, and server time

[Yaron Sheffer]

On 02/06/16 18:16, David Benjamin wrote:

On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni > wrote:


 > On Jun 2, 2016, at 10:49 AM, David Benjamin
> wrote:
 >
 > I'm not sure I follow. The specification certainly spells out how
version negotiation is supposed to work. That hasn't stopped servers
from getting it wrong. Fundamentally this is the sort of thing where
bugs don't get noticed until we make a new TLS version, and we don't
do that often enough to keep rust from gathering.

A better way to keep rust from gathering is to not instutionalize
fallback,
force the broken sites to deal with the issue.  While 2% is
noticeable, you
can probably drive 1.3 version intolerance out of the ecosystem
relatively
quickly if Chrome implements fallback for a limited time (say 6
months after
TLS 1.3 RFC is done) and with a diminishing probability (60% first
month, 10%
less each month thereafter), season to taste.


I've mused on something like that (I was the main driver behind
painstakingly removing the existing version fallback in Chrome), but I
don't think non-determinism is a good idea. Site owners need to be able
to reproduce the failures their users see.

But, yes, I will of course be monitoring the true metrics (my probing a
list of sites is only an approximation) and seeing what can be done
here, as I did previously.

David



Taking Viktor's proposal in a different direction, you could gradually 
increase the probability of version intolerance on the client side while 
still remaining deterministic from the user's point of view. You could 
do it by choosing a random distribution over server names (e.g., a hash 
of the SNI value). This means every month a few new servers would break. 
And you would want the client's beta channel to run several steps ahead 
of the production version.


Thanks,
Yaron

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

Re: [TLS] PR #493: Multiple concurrent tickets

[Yaron Sheffer]

Hi EKR,

This is confusing: on the one hand you encourage clients to use multiple 
tickets when available, "to the extent possible use a different one for 
each new connection", and on the other hand you say that a simple way to 
follow the Generation policy is to keep only the latest ticket, and then 
presumably to use it multiple times.


Can you please expand on the motivation here? Do we assume that a 
browser normally opens (say) 5 connections concurrently and we want each 
one to use fresh/separate key material? If so, maybe the client should 
indicate how much concurrency it plans to use?


I think we would all be happier if the security proofs hold even if 
clients use the same ticket again and again.


Thanks,
Yaron

On 04/06/16 18:51, Eric Rescorla wrote:

https://github.com/tlswg/tls13-spec/pull/493

Currently the server can send multiple tickets but we don't say anything
about the semantics.
So, say a server sends tickets T_1, T_2, T_3... T_n, and the client
wants to initiate m < n connections, should he use:

- only T_n
- T_1...T_m
- T_n, T_n-1, ... T_n-m+1

The intuition I have had is that we want the third option (latest wins,
but allow multiples for linkability) but the spec doesn't say and there
aren't any semantics that tell you, so I think we want some way for the
server to say "these group of tickets are all co-valid".

I've just created PR#493, which provides an explicit mechanism for this,
"ticket generations". Tickets with the same generation M are co-valid
and a ticket with generation N expires all tickets with generation M <
N. The nice thing about this encoding is that a client can implement the
old "one ticket at a time" behavior by just ignoring the generation and
taking the last ticket.

I wanted to call out to cryptographers/analysts that this formalizes the
existing practice (going back to RFC 5077) of having multiple ticket
values tied to the same basic secret (though less so with 1.3 because
tickets issued on connection N+1 don't have the same RMS as those on
connection N). If there is a problem with this, that would be good to know.

Barring major objections, I'll merge this Thursday.


-Ekr




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



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

Re: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors

[Yaron Sheffer]

This still makes the *stateful* implementation much more deterministic 
and those implementations are common enough. So how about:


Alert messages with a level of fatal result in the immediate termination 
of the connection. In this case, other connections corresponding to the 
session may continue, but the session identifier MUST be invalidated, 
preventing the failed session from being used to establish new 
connections. This requirement does not apply when the server's 
implementation of session resumption is stateless.


Thanks,
Yaron

On 22/05/16 01:11, Eric Rescorla wrote:

https://github.com/tlswg/tls13-spec/issues/471


http://tlswg.github.io/tls13-spec/#alert-protocol says:

"Alert messages with a level of fatal result in the immediate
termination of the connection. In this case, other connections
corresponding to the session may continue, but the session identifier
MUST be invalidated, preventing the failed session from being used to
establish new connections."

However, this is not consistent with a stateless implementation of
session tickets.
RFC5077 is a bit handwavy on this but implies that you shouldn't do this
with tickets
(see also [SBR04] for discussion of this). I propose we remove this
requirement


-Ekr


[SBR04] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
   caching for TLS", Transactions on Information and System
   Security (TISSEC) , Volume 7, Issue 4, November 2004.




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



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

[TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt

[Yaron Sheffer]

The draft describes using an opaque ticket (similar to a session 
resumption ticket) to pin the identity of a TLS server. The new version 
addresses several comments on this list, in particular regarding the 
message syntax, and requesting a comparison with TACK - thanks Dave and 
Daniel.


Thanks,
Yaron


 Forwarded Message 
Subject: 	New Version Notification for 
draft-sheffer-tls-pinning-ticket-01.txt

Date:   Sat, 06 Feb 2016 12:25:54 -0800
From:   internet-dra...@ietf.org
To: Yaron Sheffer <yaronf.i...@gmail.com>



A new version of I-D, draft-sheffer-tls-pinning-ticket-01.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-tls-pinning-ticket
Revision:   01
Title:  TLS Server Identity Pinning with Tickets
Document date:  2016-02-06
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/
Htmlized:   https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-01

Abstract:
   Fake public-key certificates are an ongoing problem for users of TLS.
   Several solutions have been proposed, but none is currently in wide
   use.  This document proposes to extend TLS with opaque tickets,
   similar to those being used for TLS session resumption, as a way to
   pin the server's identity.  That is, to ensure the client that it is
   connecting to the right server even in the presence of corrupt
   certificate authorities and fake certificates.  The main advantage of
   this solution is that no manual management actions are required.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

[TLS] TLS 1.3 comments

[Yaron Sheffer]

  
  
Below a long list of comments, generally minor. The document is
already very good - we're making great progress!

  The record length field is limited by encrypted-length+2048.
Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an
expansion of greater than 1024 bytes".
  6: the definition of session contents should also contain
identities. The client's identity, if authenticated by cert, or
the peers' PSK identity.
  "Access denied" alert: the description starts with "a valid
certificate was received", but it may also apply to PSK.
  Handshake_failure alert seems to be synonymous with
insufficient_security (and Sec. 6.2.1 proves it...). Can we
clarify the difference, or deprecate one of them?
  Typo: "via a certificates".
  Server Configuration: how does the client know to whom the
configuration applies? For example if I connected to
"*.example.com" (a wildcard cert) and now I connect to
"srv.example.com", should I use the stored configuration?
  6.2.2: typo: has complete.
  6.3.2.3.2: it's time we specified that the recipient (in this
case, the server) MUST verify the received ECDHE public key (see
RFC 6989). This is mentioned in Appendix D but only for modular
DH.
  6.3.2.4: "identifier" should read "identity".
  6.3.4: "Perhaps have a whitelist of which extensions can be
unencrypted and everything else MUST be encrypted." - this
doesn't work, because we might come up in the future with an
extension that needs to be unprotected. Maybe we can say
"SHOULD" instead.
  6.3.7: expiration_date: there's no reason to force/assume time
synchronization between client and server. This can just as well
be relative time (number of seconds since negotiation), like
ticket_lifetime_hint.
  6.3.10: "If the client does not send any certificates, the
server MAY at its discretion either continue the handshake
without client authentication ... Also, if some aspect of the
certificate chain was unacceptable ... the server MAY at its
discretion either continue the handshake (considering the client
unauthenticated) or send a fatal alert." This is strange. There
is no way for the client to understand that the server considers
it unauthenticated and modify its behavior accordingly. A
warning alert would be appropriate here, even if in general we
don't like warning alerts.
  Typo: main-in-the-middle
  "Note that using non-anonymous key exchange without actually
verifying the key exchange is essentially equivalent to
anonymous key exchange, and the same precautions apply. " This
is not precisely true, because the other peer may not know that
you're not verifying the exchange, and so it might behave
differently.
  D.1.2: do we really need to worry about version rollback to
SSLv2? I suggest to remove this section.

Thanks,
    Yaron
  


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