Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

[Carrick Bartle]

The points brought up in this thread have already been discussed, after
which the chairs decided there was rough consensus to deprecate FFDHE and
RSA and moved the document to WGLC. In particular, Hubert suggested last
December to add a warning that FFDHE should be preferred over RSA, even
though the document deprecates both of them:
https://mailarchive.ietf.org/arch/msg/tls/SPqcyUajXPVqmHiyEHm-d5JWfbw/

On Fri, Jul 14, 2023 at 10:41 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> AFAIK, they aren’t on TLS 1.3, at least so far.
>
> Regards,
> Uri
>
> > On Jul 14, 2023, at 12:54, Peter Gutmann 
> wrote:
> >
> > !---|
> >  This Message Is From an External Sender
> >  This message came from outside the Laboratory.
> > |---!
> >
> > Blumenthal, Uri - 0553 - MITLL  writes:
> >
> >> I’m aware of at least one company (using the term loosely) that uses
> custom
> >> group,
> >
> > How does that work with TLS 1.3?
> >
> > Peter.
> >
> ___
> 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] consensus call: deprecate all FFDHE cipher suites

[Carrick Bartle]

> Telling people that they shouldn't use the only things they can use means
that the advice is unactionable, thus will be ignored.

Yep, that's precisely what people are suggesting. If someone has a legacy
system that cannot be upgraded, or they need to interface with such
systems, they can ignore the deprecation and continue to use FFDHE.


On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario  wrote:

> On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:
> > On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
> >> use of FFDHE with large key sizes is the best protection against
> >> store-and-decrypt-later attacks
> >
> > This doesn't deprecate use of FFDHE in TLS 1.3, for which we
> > have some ludicrously large named groups.  Is that not enough?
>
> Not everybody has migrated to TLS 1.3 yet. Not everybody has migrated to
> ECC.
>
> For the people that still have the only options of RSA key exchange or
> FFDHE
> key exchange, both in TLS 1.2, we need to be crystal clear that they
> should
> pick
> FFDHE.
>
> Telling people that they shouldn't use the only things they can use means
> that
> the advice is unactionable, thus will be ignored.
>
> >> If anything, RSA key exchange should be deprecated first.
> >> RFC 8446 deprecated only the DSA ciphersuites, not RSA.
> >
> > This is an odd statement.  TLS 1.3 ciphersuites no longer
> > include the concept of key exchange or signing.
>
> Ciphersuites, yes. Protocol itself, no. It still performs a key exchange.
> And TLS 1.3 explicitly deprecates DSA, see below.
>
> > If you are talking about the signing part, both were sort of
> > deprecated.  RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only
> > usable within the certificate chain, not in the protocol.  PSS
> > was added back.
>
> There's a difference between saying that a TLS 1.3 client MUST NOT
> advertise
> client hello with TLS_RSA_* ciphersuites listed, and just having TLS 1.3
> not supporting RSA key exchange.
>
> Both of them can be called "deprecated", but one is a clearer and stronger
> condemnation than the other.
>
> DSA is effectively treated with the former "deprecation":
> RFC8446 Section 4.2.3:
>
> >  They MUST NOT be offered or negotiated by any
> >  implementation.  In particular, MD5 [SLOTH], SHA-224, and DSA
> >  MUST NOT be used.
>
> RSA key exchange has nothing like it.
>
> For me "deprecated" means "You really shouldn't use it", not "You should
> stop
> using it at the earliest convenience". I.e. MUST NOT vs SHOULD NOT.
>
> > However, for key exchange, which is more relevant to this
> > conversation, RSA was indeed removed.  And the draft we're
> > discussing does indeed say that RSA key exchange in TLS 1.2 is
> > deprecated.
> >
> > Can you help me better understand the scope of your objection?
>
> I guess my primary objection is with the subject of this thread:
> "deprecate all FFDHE cipher suites". That I don't agree with.
>
> As far as the "draft-ietf-tls-deprecate-obsolete-kex-01" text goes, I would
> tweak some things, but the general description of FFDHE state I do agree
> with:
> "that you shouldn't use it in TLSv1.2, but if you have to, there are simple
> things to do to make sure you're relatively secure".
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

> the latter is basically unexploitable with properly behaving hosts in
TLSv1.2

Well, right, that's the trick. The issue that people have pointed out with
FFDHE is that it's very easy to have a host that is not properly behaving
(see RFC 7919, which is referenced in our draft).




On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario  wrote:

> On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
> > On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
> > Thus the deprecation of it is a matter of taste, not
> > cryptographic
> > necessity.
> >
> > I'm sorry if I'm being dense here, but isn't all of this a
> > SHOULD NOT in RFC 9325?
> >
> >
> https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit
> >
> > Maybe I'm misreading that RFC, but given that it's a BCP, it
> > seems like deprecation is a natural step that reflects IETF
> > consensus.
>
> that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
> Given that the former is still being exploited close to 25 years after the
> Bleichenbacher attack was discovered, while the latter is basically
> unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
> correct to consider them at the same level.
>
> Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But if
> everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far
> better
> of with TLS_DHE_*.
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

Sounds good, thanks!

On Mon, Dec 19, 2022 at 3:46 PM Rob Sayre  wrote:

> On Mon, Dec 19, 2022 at 2:52 PM Martin Thomson  wrote:
>
>> On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
>> >> You might need to clarify that TLS 1.1 and earlier are wholly
>> deprecated though, just to be sure.
>> >
>> > We do mention that in the body of the document. Are you suggesting that
>> > we also add that to the abstract and intro?
>>
>> Oh yeah, three times even.  I was looking for it in the introduction.
>> Though that intro is getting a little lengthy.  I'll leave it to your
>> judgment.
>>
>
> Yes, I'd say do something excruciatingly clear like that. The people on
> this list know what's trying to be communicated, but they don't really need
> to read the introduction.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

> You might need to clarify that TLS 1.1 and earlier are wholly deprecated
though, just to be sure.

We do mention that in the body of the document. Are you suggesting that we
also add that to the abstract and intro?

On Sun, Dec 18, 2022 at 2:55 AM Martin Thomson  wrote:

> On Sun, Dec 18, 2022, at 04:33, Yaron Sheffer wrote:
> > 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.
>
> The title and abstract and introduction could say "TLS 1.2" and the
> document would be fine.  You might need to clarify that TLS 1.1 and earlier
> are wholly deprecated though, just to be sure.
>
> ___
> 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] consensus call: deprecate all FFDHE cipher suites

[Carrick Bartle]

Good point, we'll add that to the intro and title.

On Sat, Dec 17, 2022 at 9:03 AM 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 <
> cbartle...@gmail.com>
> *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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/ShRaCsYx4lk/m/46rD81AsBwAJ>
>  and
> from BoringSSL not too long afterwards.
>
>
>
> The DHE construction in TLS 1.2 was flawed in failing to negotiate groups.
> The Logjam <https://weakdh.org/> 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
> <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-01.html#section-3-2.2>
> ("The group size is at least 2048 bits"), and the previous one
> <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-00.html#section-3-2.2>
> ("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
> <https://www.rfc-editor.org/rfc/rfc7435#section-3> ("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 the

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

[Carrick Bartle]

The fact that there are long product lifecycles makes the case for
deprecation rather than against it. Imagine that we do not deprecate DHE.
That means that next year, someone will be fully within the standard to
create a long-lived product that uses DHE with TLS 1.2 and nothing more
secure than that. That means that we can't deprecate DHE next year either
for the same reason we can't deprecate it now, and so on, forever. Is that
really the circumstance we want to find ourselves in? To never deprecate
insecure algorithms? That seems overly reckless to me and may leave new
systems vulnerable to known security issues for a long time.

Carrick






On Fri, Dec 16, 2022 at 3:22 AM Peter Gutmann 
wrote:

> Rob Sayre  writes:
>
> >For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> >endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> >areas does not constrain the rest of the internet.
>
> And for my part I'm... well not really sick of but resigned to accepting
> the
> fact that as far as the WG seems to be concerned, nothing exists outside of
> the web [*] and there's no need to accommodate anything but that.  Saying
> "lalalalala I'm not listening, I'm not listening" won't deal with the fact
> that there's a staggering amount of gear out there with product lifecycles
> sometimes measured in decades that needs a sound basis for making decisions
> about what to deploy, which this deprecation isn't providing.
>
> Maybe that's the way to resolve this, make it explicit that the deprecation
> applies for web use and not for other uses like SCADA, embedded, or
> anything
> else that needs to take long-term usage into account.
>
> Peter.
>
> [*] Once you exclude your list of IoT, SCADA, embedded, and the case I
> mentioned, transaction processing, you've pretty much ruled out
> everything but web use... well OK, admittedly there's still email (so
> opportunistic encryption) and a bunch of barely-visible stuff like any
> tunnels that for some reason don't already use IPsec/OpenVPN/WireGuard.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

> without further guidance they've chosen to go with literally the worst
possible option instead of the perfectly-OK one.
You are more than welcome to draft a document stating that, given two
deprecated options, which is preferable.

> It seems the only real reason for deprecating DHE is that it's not
fashionable.

No one has made any statements about the fashionability or otherwise of
DHE. As I stated in a different thread, this document leaves the presence
of DHE in TLS 1.3 completely unscathed. As David Ben reiterated, the
reasoning behind deprecation has been almost entirely based on the
inability to negotiate groups.



On Thu, Dec 15, 2022 at 4:26 PM Peter Gutmann 
wrote:

> Carrick Bartle  writes:
>
> >In the situation you've described, they've been told they shouldn't use
> RSA
> >either, so clearly it doesn't matter to them what we've deprecated or
> not.
>
> Yup, because if you give people the choice between not A but not B either
> then
> they have to ignore one of the two, and without further guidance they've
> chosen to go with literally the worst possible option instead of the
> perfectly-OK one.
>
> Piggybacking a reply to your other message, anything that's online is DoS-
> able.  If I want to DoS a web server, or anything at all for that matter,
> I'll
> hit it with a botnet, an attack that's effective on anything no matter what
> algorithm it uses.
>
> It seems the only real reason for deprecating DHE is that it's not
> fashionable. And as my earlier message pointed out, this WG fashion
> statement
> has real consequences in practice.
>
> Peter.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

In the situation you've described, they've been told they shouldn't use RSA
either, so clearly it doesn't matter to them what we've deprecated or not.
We should deprecate insecure algorithms; the fact that there's a spectrum
of insecurity among deprecated algorithms does not detract from the fact
that they are all best avoided.

On Wed, Dec 14, 2022 at 3:07 AM Peter Gutmann 
wrote:

> Nimrod Aviram  writes:
>
> >Let me clarify that the document also has RSA as a MUST NOT.
> >
> >So there will be no reason to read this document and switch from FFDHE to
> >RSA.
>
> If you tell people they can't have A but they can't have B either then
> they're
> going to have to choose one of the two in order to communicate, and in (at
> least some) banking it's RSA, the most insecure option there is, because
> they've been told they shouldn't use DHE.
>
> Peter.
>
> ___
> 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] consensus call: deprecate all FFDHE cipher suites

[Carrick Bartle]

> Wouldn’t be the first case an RFC gets misinterpreted.

I don't think the IETF's decisions should be dictated by the risk that
someone might potentially misread their documents. That's always a risk.
Someone might misread RFC 8446 as saying "use SSL 3.0 only." Does that mean
the IETF shouldn't publish RFC 8446?

> use depreciation as an excuse to remove support of deprecated algorithms
and protocols.

I'm not sure what the issue is here. Deprecation isn't just an excuse to
remove support of deprecated protocols; it's a good reason to do so. If,
however, they need to interface with legacy systems, they can continue to
do so in spite of official deprecation. No one is going to arrest them for
continuing to use FFDHE.

Carrick


On Wed, Dec 14, 2022 at 5:01 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> True - but, unfortunately, quite a few readers misunderstand that and use
> depreciation as an excuse to remove support of deprecated algorithms and
> protocols.
>
> Wouldn’t be the first case an RFC gets misinterpreted.
>
> Regards,
> Uri
>
> On Dec 14, 2022, at 02:30, Rob Sayre  wrote:
>
> 
> On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:\
>
>>
>>
>> I think I’ve made my point already – there are devices that use FFDHE,
>> which remain secure (so far), and may require access by new .
>> Thus, an RFC that would prohibit it, sounds, as you said yourself,
>> premature.
>>
>
> Deprecated does not mean prohibited.
>
> thanks,
> Rob
>
> ___
> 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] consensus call: deprecate all FFDHE cipher suites

[Carrick Bartle]

> I certainly am, especially given that there are no security reasons
driving it.

Could you describe your reasoning behind this statement? From my read,
supporters of deprecation have made it pretty clear that the motivation
behind deprecating DHE is security considerations: there is no way to
securely negotiate it without introducing potential DoS issues.


On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Maybe you are saying this decision is premature.
>
>
>
> I certainly am, especially given that there are no security reasons
> driving it.
>
>
>
> Surely there is a limit to this reasoning, though.
>
>
>
> Of course.
>
>
>
> There is a MacOS 9 system right next to me, and it doesn't support
> anything beyond SSL3. I would not expect the IETF to accommodate that
> system.
>
>
>
> Correct. And I wouldn’t expect the IETF to accommodate whatever Windows 95
> used to support, if anybody still has it. But, as you said, there’s a limit
> to this reasoning as well.
>
>
>
> So, can you explain your point a bit more?
>
>
>
> I think I’ve made my point already – there are devices that use FFDHE,
> which remain secure (so far), and may require access by new .
> Thus, an RFC that would prohibit it, sounds, as you said yourself,
> premature.
>
>
>
> I think "zero security reasons" sounds like something we should work out,
> but arguments like "who cares for systems like SCADA" are a bit off the
> mark. The IETF can't perpetually support systems that can't be upgraded,
> because attacks always get better.
>
>
>
> I see a great distance between “perpetual” and “premature”. And SCADA is
> just one area, which I brought up because it’s closer to me than, e.g.,
> browsers-and-websites realm.
>
>
>
> And stand by my opinion that deprecating a perfectly functional and secure
> protocol (for reasons I consider frivolous at best) and ignore the likely
> harm such deprecation would cause, is, er, “premature”.
>
>
>
>
>
>
>
> thanks,
>
> Rob
>
>
>
>
>
> On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> That sounds like deprecation to me (stop building new things this way...)
>
>
>
> Build new things that stop interoperating with old things? Does not sound
> smart to me.
>
>
>
> Not to mention that there’s zero security reasons for this deprecation.
>
>
>
> I support deprecating all FFDHE cipher suites. The IETF should not
> perpetually support systems that can't be upgraded.
>
>
>
> Yeah, who cares for systems like SCADA. Sure.
>
>
>
>
>
> On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I do not support deprecation, because there will be deployed devices (IoT,
> SCADA) that aren’t upgradable – and the new stuff will have to access them.
>
>
>
> I’ll spare the group my personal opinion about this draft.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> *From: *TLS  on behalf of Ira McDonald <
> blueroofmu...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 10:47
> *To: *Sean Turner , Ira McDonald 
> *Cc: *TLS List 
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
>
> Hi,
>
>
>
> Yes - I support deprecating all FFDHE cipher suites including well-known
> groups.
>
>
>
> Cheers,
>
> - Ira
>
>
>
>
>
> 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Carrick Bartle]

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

Re: [TLS] Deprecating Obsolete Key Exchange Methods in TLS

[Carrick Bartle]

> NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange.
> 
> 
> Yes, but this has no bearing on why it's deprecated.


+1. The PQ KEMs aren't relevant here.


> On Mar 2, 2022, at 10:31 AM, David Benjamin  wrote:
> 
> On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 - MITLL 
> mailto:u...@ll.mit.edu>> wrote:
> Following the discussions around draft-bartle-tls-deprecate-ffdh and 
> draft-aviram-tls-deprecate-obsolete-kex, and after consulting the chairs, we 
> have merged the two drafts into draft-aviram-tls-deprecate-obsolete-kex 
> .
> 
>  
> 
> The merged draft prescribes the following:
> 
> RSA key exchange is a MUST NOT. 
> NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange.
> 
> 
> Yes, but this has no bearing on why it's deprecated.
> 
> The question is how you use the KEM, and as well as the properties of the KEM 
> in question. In TLS 1.3, and in TLS 1.2 (EC)DHE key exchanges, the KEM 
> recipient generates an ephemeral, per-connection key. This gives us forward 
> secrecy properties, which this WG has treated as important. In TLS 1.2 RSA 
> key exchange, the recipient uses a static RSA key. In principle, one could 
> also use an RSA-based KEM with ephemeral keys, but RSA key generation is so 
> expensive that this is implausible. Regardless, "RSA key exchange" in the 
> context of TLS is specifically the TLS 1.2 RSA construction, which doesn't do 
> this.
> 
> Additionally, the particular KEM-like construction used in TLS RSA key 
> exchange is flawed, per the Bleichenbacher attack. While we have a 
> mitigation, it is just a workaround for what is ultimately a flawed 
> construction. That mitigation has also had a series of implementation issues, 
> per the documents cited by the draft.
>  
> 
> Non-ephemeral finite-field DH is a MUST NOT.
>  
> 
> Overkill, and unnecessary. Should be SHOULD NOT.
> 
>  
> 
> Non-ephemeral ECDH is a SHOULD NOT.
>  
> 
> OK.
> 
>  
> 
> Ephemeral finite-field DH (DHE) is a MAY, only when fully ephemeral, and only 
> using a well-known group of size at least 2048 bits.
>  
> 
> Overkill, though requiring sufficiently large group size is fine.
> 
>  
> 
>  
> 
> We added greater justification for point 3 
> 
>  above to address concerns previously raised on the list.
> 
>  
> 
> We'd love to hear your thoughts.
> 
>  
> 
> best wishes,
> 
> Carrick and Nimrod
> 
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

Sorry, I'm not sure what you mean?

> On Aug 28, 2021, at 6:20 PM, Rob Sayre  wrote:
> 
> On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle  <mailto:cbartle...@icloud.com>> wrote:
> All the ciphersuites mentioned in the draft under discussion are already 
> listed as not recommended because they don't offer forward secrecy.
> 
> Excellent. How much WG time should we waste on so-called "embedded" use cases?
> 
> thanks,
> Rob

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

In the revision of this draft 
(https://tools.ietf.org/pdf/draft-bartle-tls-deprecate-ffdh-00.pdf), which was 
unfortunately not the revision sent out on this call for adoption, we cite 
invalid curve attacks as a reason to advise against ECDH: 
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.704.7932=rep1=pdf

These attacks seem to me to indicate that ephemeral-static ECDH is inherently 
insecure. Do you disagree? If so, why?



> On Aug 27, 2021, at 8:25 AM, Rene Struik  wrote:
> 
> {officially on vacation till Labor Day, but weighing-in briefly}
> 
> Hi Filippo:
> 
> I had a brief look at the CVEs you referenced and at your Blackhat 2018 
> presentation. 
> 
> Some observations on your Blackhat 2018 presentaton: (a) the attack seems to 
> be a reincarnation of the so-called Goubin attack presented 19 years earlier 
> (in 1999); (b) the attack requires many (100s) of reuses of the same private 
> key string. Both the 1999 attack and your Blackhat 2018 version can be easily 
> prevented if one uses blinded private keys.
> 
> A closer look at your referenced CVEs suggests these can be classified as (i) 
> lack of checking for improperly generated DH groups; (ii) exploiting 
> overflow/underflow/carry bugs. To me, nothing seems to be new here and more 
> likely a failure of implementers to heed to results and advice predating the 
> CVEs by years (and sometimes decades) or in QA processes. E.g., with respect 
> to (i), one had not gotten oneself into trouble if one had actually bothered 
> to implement domain parameter checks. In the literature of implementation 
> attacks, OpenSSL has proven to be an excellent "implementation security flaw 
> paper generator".
> 
> I have yet to see evidence that ephemeral-static ECDH would be inherently 
> insecure.
> 
> Rene
> 
> On 2021-08-27 9:34 a.m., Filippo Valsorda wrote:
>> [snip]
>> 
>> This is empirically disproved by a number of vulnerabilities that are 
>> exploitable (or near-misses for other reasons) only in ephemeral-static 
>> mode, such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, 
>> CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and 
>> CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 
>>  gives a good explanation of how these 
>> attacks work, and you might find 
>> https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf
>>  
>> 
>>  interesting as well.
>> OpenSSL:
>> 
>> CVE-2016-0701: improper generation of Diffie-Hellman group
>> 
>> The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 
>> before 1.0.2f does not ensure that prime numbers are appropriate for 
>> Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers 
>> to discover a private DH exponent by making multiple handshakes with a peer 
>> that chose an inappropriate number, as demonstrated by a number in an X9.42 
>> file.
>> 
>> CVE-2016-7055: carry-propagation bug
>> 
>> There is a carry propagating bug in the Broadwell-specific Montgomery 
>> multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0c that 
>> handles input lengths divisible by, but longer than 256 bits. Analysis 
>> suggests that attacks against RSA, DSA and DH private keys are impossible. 
>> This is because the subroutine in question is not used in operations with 
>> the private key itself and an input of the attacker's direct choice. 
>> Otherwise the bug can manifest itself as transient authentication and key 
>> negotiation failures or reproducible erroneous outcome of public-key 
>> operations with specially crafted input. Among EC algorithms only Brainpool 
>> P-512 curves are affected and one presumably can attack ECDH key 
>> negotiation. Impact was not analyzed in detail, because pre-requisites for 
>> attack are considered unlikely. Namely multiple clients have to choose the 
>> curve in question and the server has to share the private key among them, 
>> neither of which is default behaviour. Even then only clients that chose the 
>> curve will be affected.
>> 
>> CVE-2017-3732: carry-propagation bug
>> 
>> There is a carry propagating bug in the x86_64 Montgomery squaring procedure 
>> in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No EC algorithms are 
>> affected. Analysis suggests that attacks against RSA and DSA as a result of 
>> this defect would be very difficult to perform and are not believed likely. 
>> Attacks against DH are considered just feasible (although very difficult) 
>> because most of the work necessary to deduce information about a private key 
>> may be performed offline. The amount of resources required for such an 
>> attack would be very significant and likely only accessible to a limited 
>> number of attackers. An attacker would additionally need online access to an 
>> 

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

All the ciphersuites mentioned in the draft under discussion are already listed 
as not recommended because they don't offer forward secrecy.

> On Aug 27, 2021, at 11:01 AM, Rob Sayre  wrote:
> 
> On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda  > wrote:
> 
> If a consistent history of directly linked vulnerabilities across major 
> implementations doesn't show something is unsafe, I don't think there is 
> progress to be made in the discussion. Blaming the implementers is not 
> particularly interesting to me.
> 
> Anyway, I don't have an opinion on SHOULD NOT vs MUST NOT, as long as it 
> leads to Recommended: N in the registry.
> 
> I agree. I can't think of a reason to list it as " Recommended: Y".
> 
> thanks,
> Rob
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

> >   which is a main reason cited for deprecating RSA in 
> > draft-aviram-tls-deprecate-obsolete-kex.
>  
> Have the authors look at Post-Quantum KEMs?

I'm not sure why PQ KEMs are relevant here.


> On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL 
>  wrote:
> 
> >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do 
> > not provide
> >  forward secrecy,
>  
> Unless you use semi-static exchange, which in many cases makes sense.
>  
> >   which is a main reason cited for deprecating RSA in 
> > draft-aviram-tls-deprecate-obsolete-kex.
>  
> Have the authors look at Post-Quantum KEMs?
>  
> >  Do you object to just the citation of the Raccoon attack or do you also 
> > feel that we
> >  should keep these ciphersuites that do not provide forward secrecy around?
>  
> I think these suites should stay around. 
>  
> While static-static indeed do not provide forward secrecy (and many of us – 
> though not everybody! – carry for that), static-ephemeral DH and ECDH are 
> perfectly fine from that point of view.
>  
>  
>  
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL 
> mailto:u...@ll.mit.edu>> wrote:
>> I agree with Rene’s points.
>>  
>> -- 
>> Regards,
>> Uri
>>  
>>  
>> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
>> Rene Struik mailto:rstruik@gmail.com>>
>> Date: Friday, August 13, 2021 at 09:58
>> 
>> Dear colleagues:
>>  
>> I think this document should absolutely *not* be adopted, without providing 
>> far more technical justification. The quoted Raccoon attack is an easy to 
>> mitigate attack (which has nothing to do with finite field groups, just with 
>> poor design choices of postprocessing, where one uses variable-size integer 
>> representations for a key). There are also good reasons to have key 
>> exchanges where one of the parties has a static key, whether ecc-based or 
>> ff-based (e.g., sni, opaque), for which secure implementations are known. No 
>> detail is provided and that alone should be sufficient reason to not adopt.
>>  
>> Rene
>>  
>> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
>>> This is a working group call for adoption for Deprecating FFDH(E) 
>>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>>> ). We 
>>> had a presentation for this draft at the IETF 110 meeting and since it is a 
>>> similar topic to the key exchange deprecation draft the chairs want to get 
>>> a sense if the working group wants to adopt this draft (perhaps the drafts 
>>> could be merged if both move forward).  Please review the draft and post 
>>> your comments to the list by Friday, August 13, 2021.  
>>>  
>>> Thanks,
>>>  
>>> The TLS chairs
>>>  
>>> 
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/tls 
>>>  
>> 
>> -- 
>> email: rstruik@gmail.com  | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> ___
> 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-cross-sni-resumption

[Carrick Bartle]

I've submitted a PR that addresses this issue: 
https://github.com/vasilvv/tls-cross-sni-resumption/pull/3 
<https://github.com/vasilvv/tls-cross-sni-resumption/pull/3>

In general though, I support publication of this draft.


> On Aug 11, 2021, at 3:50 PM, Carrick Bartle 
>  wrote:
> 
> Okay, in that case, I wouldn't use the word "re-validated," since to me that 
> sounds like the certificate is to be completely validated again (e.g. 
> checking expiration). Instead I would say something like "attempt resumption 
> only if the certificate is valid for the new SNI," ideally with a reference 
> to the current best practice of how to do that.
> 
> 
> 
>> On Aug 11, 2021, at 3:25 PM, David Benjamin > <mailto:david...@chromium.org>> wrote:
>> 
>> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle > <mailto:cbartle...@icloud.com>> wrote:
>>> - Ticket-based PSKs carry over the server certificate from the previous 
>>> connection
>> 
>> What does "carry over" mean here? That the client literally holds on to the 
>> certificate and re-evaluates it before resumption? Or just that the trust 
>> from evaluating the certificate during the initial handshake also applies to 
>> the PSK? Because, AFAICT, the literal ticket isn't required to contain the 
>> server certificate.
>> 
>> I meant the latter. Though every TLS stack I've seen does actually retain 
>> the peer certificate. It's not in the literal ticket (that wouldn't work 
>> since it's issued by the server), but in the session state the client stores 
>> alongside the ticket, just like the PSK and other state. This is because TLS 
>> APIs typically have some kind of function to get the peer certificate, and 
>> applications typically expect that function to work consistently for all 
>> connections. That stuff is mostly not in the RFCs because it's local state 
>> and TLS doesn't define an API.
>> 
>> Anyway, as with any other use of resumption, in order to offer a ticket, you 
>> need to have retained enough information locally to know that the trust from 
>> the initial handshake is also good for this connection. This could be 
>> remembering application context (perhaps by way of separate session caches). 
>> This could be remembering the whole certificate. This could be remembering 
>> smaller amounts of information from the certificate. The exact details here 
>> I don't think TLS should specify, only the conditions on when using a 
>> session is okay.
>> 
>> David
>>  
>>> On Aug 11, 2021, at 2:13 PM, David Benjamin >> <mailto:david...@chromium.org>> wrote:
>>> 
>>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 
>>> >> <mailto:40icloud@dmarc.ietf.org>> wrote:
>>> >  Notably, it still relies on the server certificate being re-validated 
>>> > against the new SNI at the
>>> >  session resumption time.
>>> 
>>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed 
>>> it.)
>>> 
>>> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, 
>>> if it says anything useful, it's implicit in how resumption works:
>>> 
>>> - If the client offers a PSK, it must be okay with the server 
>>> authenticating as that PSK for this connection
>>> - Ticket-based PSKs carry over the server certificate from the previous 
>>> connection
>>> - Therefore, in order to offer a ticket in a connection, the client must be 
>>> okay with that previous server certificate in the context of that 
>>> connection. Server name, trust anchors, and all.
>>> 
>>> This is another one of those cases where cross-SNI resumption is just a 
>>> more obvious example of a general principle that needs to be written down 
>>> somewhere in TLS proper. (Even with the same SNI, suppose two different 
>>> parts of my application use different trust stores. My session resumption 
>>> decisions must be consistent with that.)
>>>  
>>> >  However, in the absence of additional signals, it discourages using a 
>>> > session ticket when the SNI value > does not match ([RFC8446], Section 
>>> > 4.6.1), as there is normally no reason to assume that all servers
>>> > sharing the same certificate would also share the same session keys.
>>> 
>>> It'd be helpful to describe under what circumstances there is reason to 
>>> assume that servers that share the same certificate also share the same 
>>> session ke

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

[Carrick Bartle]

Okay, in that case, I wouldn't use the word "re-validated," since to me that 
sounds like the certificate is to be completely validated again (e.g. checking 
expiration). Instead I would say something like "attempt resumption only if the 
certificate is valid for the new SNI," ideally with a reference to the current 
best practice of how to do that.



> On Aug 11, 2021, at 3:25 PM, David Benjamin  wrote:
> 
> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle  <mailto:cbartle...@icloud.com>> wrote:
>> - Ticket-based PSKs carry over the server certificate from the previous 
>> connection
> 
> What does "carry over" mean here? That the client literally holds on to the 
> certificate and re-evaluates it before resumption? Or just that the trust 
> from evaluating the certificate during the initial handshake also applies to 
> the PSK? Because, AFAICT, the literal ticket isn't required to contain the 
> server certificate.
> 
> I meant the latter. Though every TLS stack I've seen does actually retain the 
> peer certificate. It's not in the literal ticket (that wouldn't work since 
> it's issued by the server), but in the session state the client stores 
> alongside the ticket, just like the PSK and other state. This is because TLS 
> APIs typically have some kind of function to get the peer certificate, and 
> applications typically expect that function to work consistently for all 
> connections. That stuff is mostly not in the RFCs because it's local state 
> and TLS doesn't define an API.
> 
> Anyway, as with any other use of resumption, in order to offer a ticket, you 
> need to have retained enough information locally to know that the trust from 
> the initial handshake is also good for this connection. This could be 
> remembering application context (perhaps by way of separate session caches). 
> This could be remembering the whole certificate. This could be remembering 
> smaller amounts of information from the certificate. The exact details here I 
> don't think TLS should specify, only the conditions on when using a session 
> is okay.
> 
> David
>  
>> On Aug 11, 2021, at 2:13 PM, David Benjamin > <mailto:david...@chromium.org>> wrote:
>> 
>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 
>> > <mailto:40icloud@dmarc.ietf.org>> wrote:
>> >  Notably, it still relies on the server certificate being re-validated 
>> > against the new SNI at the
>> >  session resumption time.
>> 
>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)
>> 
>> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, 
>> if it says anything useful, it's implicit in how resumption works:
>> 
>> - If the client offers a PSK, it must be okay with the server authenticating 
>> as that PSK for this connection
>> - Ticket-based PSKs carry over the server certificate from the previous 
>> connection
>> - Therefore, in order to offer a ticket in a connection, the client must be 
>> okay with that previous server certificate in the context of that 
>> connection. Server name, trust anchors, and all.
>> 
>> This is another one of those cases where cross-SNI resumption is just a more 
>> obvious example of a general principle that needs to be written down 
>> somewhere in TLS proper. (Even with the same SNI, suppose two different 
>> parts of my application use different trust stores. My session resumption 
>> decisions must be consistent with that.)
>>  
>> >  However, in the absence of additional signals, it discourages using a 
>> > session ticket when the SNI value > does not match ([RFC8446], Section 
>> > 4.6.1), as there is normally no reason to assume that all servers
>> > sharing the same certificate would also share the same session keys.
>> 
>> It'd be helpful to describe under what circumstances there is reason to 
>> assume that servers that share the same certificate also share the same 
>> session keys (and are able to take advantage of cross-SNI resumption).
>> 
>> 
>> > On Jul 30, 2021, at 6:57 PM, Christopher Wood > > <mailto:c...@heapingbits.net>> wrote:
>> > 
>> > Given the few responses received thus far, we're going to extend this WGLC 
>> > for another two weeks. It will now conclude on August 13.
>> > 
>> > Best,
>> > Chris, for the chairs
>> > 
>> > On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
>> >> This is the working group last call for the "Transport Layer Security 
>> >> (TLS) Resumption across Server Na

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

[Carrick Bartle]

> - Ticket-based PSKs carry over the server certificate from the previous 
> connection

What does "carry over" mean here? That the client literally holds on to the 
certificate and re-evaluates it before resumption? Or just that the trust from 
evaluating the certificate during the initial handshake also applies to the 
PSK? Because, AFAICT, the literal ticket isn't required to contain the server 
certificate.


> On Aug 11, 2021, at 2:13 PM, David Benjamin  wrote:
> 
> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 
> mailto:40icloud@dmarc.ietf.org>> 
> wrote:
> >  Notably, it still relies on the server certificate being re-validated 
> > against the new SNI at the
> >  session resumption time.
> 
> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)
> 
> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, 
> if it says anything useful, it's implicit in how resumption works:
> 
> - If the client offers a PSK, it must be okay with the server authenticating 
> as that PSK for this connection
> - Ticket-based PSKs carry over the server certificate from the previous 
> connection
> - Therefore, in order to offer a ticket in a connection, the client must be 
> okay with that previous server certificate in the context of that connection. 
> Server name, trust anchors, and all.
> 
> This is another one of those cases where cross-SNI resumption is just a more 
> obvious example of a general principle that needs to be written down 
> somewhere in TLS proper. (Even with the same SNI, suppose two different parts 
> of my application use different trust stores. My session resumption decisions 
> must be consistent with that.)
>  
> >  However, in the absence of additional signals, it discourages using a 
> > session ticket when the SNI value > does not match ([RFC8446], Section 
> > 4.6.1), as there is normally no reason to assume that all servers
> > sharing the same certificate would also share the same session keys.
> 
> It'd be helpful to describe under what circumstances there is reason to 
> assume that servers that share the same certificate also share the same 
> session keys (and are able to take advantage of cross-SNI resumption).
> 
> 
> > On Jul 30, 2021, at 6:57 PM, Christopher Wood  > <mailto:c...@heapingbits.net>> wrote:
> > 
> > Given the few responses received thus far, we're going to extend this WGLC 
> > for another two weeks. It will now conclude on August 13.
> > 
> > Best,
> > Chris, for the chairs
> > 
> > On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
> >> This is the working group last call for the "Transport Layer Security 
> >> (TLS) Resumption across Server Names" draft, available here:
> >> 
> >>https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/ 
> >> <https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/>
> >> 
> >> Please review this document and send your comments to the list by July 
> >> 30, 2021. The GitHub repository for this draft is available here:
> >> 
> >>https://github.com/vasilvv/tls-cross-sni-resumption 
> >> <https://github.com/vasilvv/tls-cross-sni-resumption>
> >> 
> >> Thanks,
> >> Chris, on behalf of the chairs
> >> 
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org <mailto:TLS@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/tls 
> >> <https://www.ietf.org/mailman/listinfo/tls>
> >> 
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org <mailto:TLS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tls 
> > <https://www.ietf.org/mailman/listinfo/tls>
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <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-cross-sni-resumption

[Carrick Bartle]

>  Notably, it still relies on the server certificate being re-validated 
> against the new SNI at the
>  session resumption time.

Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)

>  However, in the absence of additional signals, it discourages using a 
> session ticket when the SNI value > does not match ([RFC8446], Section 
> 4.6.1), as there is normally no reason to assume that all servers
> sharing the same certificate would also share the same session keys.

It'd be helpful to describe under what circumstances there is reason to assume 
that servers that share the same certificate also share the same session keys 
(and are able to take advantage of cross-SNI resumption).


> On Jul 30, 2021, at 6:57 PM, Christopher Wood  wrote:
> 
> Given the few responses received thus far, we're going to extend this WGLC 
> for another two weeks. It will now conclude on August 13.
> 
> Best,
> Chris, for the chairs
> 
> On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
>> This is the working group last call for the "Transport Layer Security 
>> (TLS) Resumption across Server Names" draft, available here:
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
>> 
>> Please review this document and send your comments to the list by July 
>> 30, 2021. The GitHub repository for this draft is available here:
>> 
>>https://github.com/vasilvv/tls-cross-sni-resumption
>> 
>> Thanks,
>> Chris, on behalf of the chairs
>> 
>> ___
>> 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] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Carrick Bartle]

I support adoption.

> On Jul 29, 2021, at 2:50 PM, Joseph Salowey  wrote:
> 
> This is a working group call for adoption of Deprecating Obsolete Key 
> Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00 
> ). 
>  There was support for adopting this draft at the IETF 111 meeting.  Please 
> review the draft and post your comments to the list by Friday, August 13, 
> 2021.  
> 
> Thanks,
> 
> The TLS chairs
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

I've posted a revision here: 
https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdh/ 
<https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdh/>


> On Jul 30, 2021, at 11:56 AM, Carrick Bartle 
>  wrote:
> 
> Sorry, the title will be changed in the next version, which I'll be posting 
> as soon as possible. You are correct about the scope of the work.
> 
> 
>> On Jul 29, 2021, at 5:41 PM, Martin Thomson > <mailto:m...@lowentropy.net>> wrote:
>> 
>> I support the *contents* of this document.  The title, however, I can't 
>> agree to.  So I want to be clear about the scope of the work, namely 
>> deprecating semi-static FFDH and ECDH suites and any use of FFDHE ephemeral 
>> suites with reused keys.
>> 
>> The draft limits the ban on ephemeral key reuse to FFDHE, which is right; I 
>> could tolerate a prohibition on reuse for ECDH, but I know that we rely on 
>> that for HPKE and other things, so it can't really be bad enough to ban.
>> 
>> Cheers,
>> Martin
>> 
>> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
>>> This is a working group call for adoption for Deprecating FFDH(E) 
>>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>>> <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/ 
>>> <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>>). 
>>> We had a presentation for this draft at the IETF 110 meeting and since 
>>> it is a similar topic to the key exchange deprecation draft the chairs 
>>> want to get a sense if the working group wants to adopt this draft 
>>> (perhaps the drafts could be merged if both move forward).  Please 
>>> review the draft and post your comments to the list by Friday, August 
>>> 13, 2021.  
>>> 
>>> Thanks,
>>> 
>>> The TLS chairs
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <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] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Carrick Bartle]

Is there benefit in stating that the server SHOULD choose a safe group, even if 
the client is unable to negotiate one?

Either way, I would support deprecating FFDHE completely.


> On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni  wrote:
> 
> On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote:
> 
>>> Was it wrong to generate server-side DH parameters?
>> 
>> The problem is that it is hard for the client to distinguish between a
>> well designed server vs a server that isn't as well written, and
>> selects the DH group in a naïve way.
> 
> I am well aware that verifying the safety of the server's choice is
> computationally taxing.
> 
>> Now, as I mentioned in the WG meeting, it would be possible to detect
>> if the server proposes a safe prime (it's not especially cheap, being
>> several times as expensive as the rest of the DH operations, but it's
>> possible), and that would prevent most of the problems that can happen
> 
> I don't think it is realistic for the client to go to that much trouble.
> The server's choice of parameters is signed by the server's public key.
> What is the threat model here?  Is the client trying to avoid servers
> that shoot themselves in the foot by verifiably choosing bad parameters?
> 
> The server could also have a strong DH group, but a terrible RNG with a
> well known RSA private key:
> 
>http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html
> 
> If the server is not one of these or similar, and attests to its choice
> of DH parameters, and they happen to be less than ideal, so be it.
> Server operators should be encouraged to choose strong parameters, but I
> see little reason for clients to second-guess that choice.
> 
> If the DH parameter size is below a reasonable threshold (Logjam), a
> client might balk, but otherwise I am not sure what practical problem
> we're actually solving.
> 
>> Of course, this works only if the legacy servers you are talking about
>> actually do use safe primes...
> 
> All the ones I know of use "openssl dhparam", which defaults to Sophie
> Germain strong primes with generator 2.
> 
> I strongly doubt there's a non-negligible server population with weak
> locally generated groups.  The only likely source of weak groups is
> servers that used one the older now deemed weak groups published in
> deprecated RFCs.
> 
> So it might suffice to refuse specific known weak "standard" groups,
> which would have a much lower impact than requiring particular standard
> groups with no mechanism to negotiate these.
> 
> -- 
>Viktor.
> 
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

Hi Martin,

Actually, a clarification question (more relevant to the other thread 

 : are you opposed to fully deprecating FFDHE? If so, why?


> On Jul 29, 2021, at 5:41 PM, Martin Thomson  wrote:
> 
> I support the *contents* of this document.  The title, however, I can't agree 
> to.  So I want to be clear about the scope of the work, namely deprecating 
> semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with 
> reused keys.
> 
> The draft limits the ban on ephemeral key reuse to FFDHE, which is right; I 
> could tolerate a prohibition on reuse for ECDH, but I know that we rely on 
> that for HPKE and other things, so it can't really be bad enough to ban.
> 
> Cheers,
> Martin
> 
> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
>> This is a working group call for adoption for Deprecating FFDH(E) 
>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>> > >). 
>> We had a presentation for this draft at the IETF 110 meeting and since 
>> it is a similar topic to the key exchange deprecation draft the chairs 
>> want to get a sense if the working group wants to adopt this draft 
>> (perhaps the drafts could be merged if both move forward).  Please 
>> review the draft and post your comments to the list by Friday, August 
>> 13, 2021.  
>> 
>> Thanks,
>> 
>> The TLS chairs
>> ___
>> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Carrick Bartle]

Sorry, the title will be changed in the next version, which I'll be posting as 
soon as possible. You are correct about the scope of the work.


> On Jul 29, 2021, at 5:41 PM, Martin Thomson  wrote:
> 
> I support the *contents* of this document.  The title, however, I can't agree 
> to.  So I want to be clear about the scope of the work, namely deprecating 
> semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with 
> reused keys.
> 
> The draft limits the ban on ephemeral key reuse to FFDHE, which is right; I 
> could tolerate a prohibition on reuse for ECDH, but I know that we rely on 
> that for HPKE and other things, so it can't really be bad enough to ban.
> 
> Cheers,
> Martin
> 
> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
>> This is a working group call for adoption for Deprecating FFDH(E) 
>> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
>> > >). 
>> We had a presentation for this draft at the IETF 110 meeting and since 
>> it is a similar topic to the key exchange deprecation draft the chairs 
>> want to get a sense if the working group wants to adopt this draft 
>> (perhaps the drafts could be merged if both move forward).  Please 
>> review the draft and post your comments to the list by Friday, August 
>> 13, 2021.  
>> 
>> Thanks,
>> 
>> The TLS chairs
>> ___
>> 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] Editorial: chronological order in ECH draft

[Carrick Bartle]

Thanks for the feedback, all!

> On Jun 23, 2021, at 4:50 PM, Christopher Patton 
>  wrote:
> 
> +1 to new readers! I think a chronological description would be a good 
> starting point, though like MT, I suspect there would be rearranging to do 
> afterwards that would break with a strictly chronological description.
> 
> Chris P.
> 
> On Wed, Jun 23, 2021 at 4:48 PM Stephen Farrell  <mailto:stephen.farr...@cs.tcd.ie>> wrote:
> 
> 
> On 24/06/2021 00:37, Martin Thomson wrote:
> > Whatever you can do to improve the readability of this document would
> > be greatly appreciated. 
> 
> +1 though I have to admit I've really been mostly looking
> at diffs at this stage - probably some new readers/coders
> are needed,
> 
> S.
> 
> > It's a complicated design and I always spend
> > far too much time trying to find answers to my questions.  A better
> > structure would be appreciated.
> > 
> > I do find that questions aren't always about behaviour.  They are
> > also about protocol elements, and those a scattered piecemeal
> > throughout.  So I would be disappointed if any restructuring were
> > limited to just getting the time sequence straightened out.
> > 
> > On Thu, Jun 24, 2021, at 09:04, Carrick Bartle wrote:
> >> Hi all,
> >> 
> >> I'm bringing
> >> https://github.com/tlswg/draft-ietf-tls-esni/issues/412 
> >> <https://github.com/tlswg/draft-ietf-tls-esni/issues/412> to the list
> >> since it looks like we're (hopefully) getting close to the end game
> >> with ECH.
> >> 
> >> The ECH draft is currently organized such that it describes all
> >> client behavior and then all server behavior. Personally, I find
> >> this very confusing to follow, and I'm constantly having to flip
> >> back and forth between sections (which themselves constantly refer
> >> to each other). Does anyone object to my rearranging the content to
> >> be in more of the order in which things occur rather than being
> >> divided into client and server sections? Of course, depending on
> >> how I do it, it could end up being *more* confusing, but I just
> >> wanted to see if people were opposed to it in principle.
> >> 
> >> Carrick ___ TLS mailing
> >> list TLS@ietf.org <mailto:TLS@ietf.org> 
> >> https://www.ietf.org/mailman/listinfo/tls 
> >> <https://www.ietf.org/mailman/listinfo/tls>
> >> 
> > 
> > ___ TLS mailing list 
> > TLS@ietf.org <mailto:TLS@ietf.org> 
> > https://www.ietf.org/mailman/listinfo/tls 
> > <https://www.ietf.org/mailman/listinfo/tls>
> > 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <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] Editorial: chronological order in ECH draft

[Carrick Bartle]

Cool. I might leave that for a different PR, but if something along those lines 
seems obvious or necessary, I'll go ahead and do it.


> On Jun 23, 2021, at 4:37 PM, Martin Thomson  wrote:
> 
> Whatever you can do to improve the readability of this document would be 
> greatly appreciated.  It's a complicated design and I always spend far too 
> much time trying to find answers to my questions.  A better structure would 
> be appreciated.
> 
> I do find that questions aren't always about behaviour.  They are also about 
> protocol elements, and those a scattered piecemeal throughout.  So I would be 
> disappointed if any restructuring were limited to just getting the time 
> sequence straightened out.
> 
> On Thu, Jun 24, 2021, at 09:04, Carrick Bartle wrote:
>> Hi all,
>> 
>> I'm bringing https://github.com/tlswg/draft-ietf-tls-esni/issues/412 to 
>> the list since it looks like we're (hopefully) getting close to the end 
>> game with ECH.
>> 
>> The ECH draft is currently organized such that it describes all client 
>> behavior and then all server behavior. Personally, I find this very 
>> confusing to follow, and I'm constantly having to flip back and forth 
>> between sections (which themselves constantly refer to each other). 
>> Does anyone object to my rearranging the content to be in more of the 
>> order in which things occur rather than being divided into client and 
>> server sections? Of course, depending on how I do it, it could end up 
>> being *more* confusing, but I just wanted to see if people were opposed 
>> to it in principle.
>> 
>> Carrick
>> ___
>> 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] Editorial: chronological order in ECH draft

[Carrick Bartle]

Hi all,

I'm bringing https://github.com/tlswg/draft-ietf-tls-esni/issues/412 to the 
list since it looks like we're (hopefully) getting close to the end game with 
ECH.

The ECH draft is currently organized such that it describes all client behavior 
and then all server behavior. Personally, I find this very confusing to follow, 
and I'm constantly having to flip back and forth between sections (which 
themselves constantly refer to each other). Does anyone object to my 
rearranging the content to be in more of the order in which things occur rather 
than being divided into client and server sections? Of course, depending on how 
I do it, it could end up being more confusing, but I just wanted to see if 
people were opposed to it in principle.

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

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

[Carrick Bartle]

> That in turn implies that getting an IP-based certificate might be easier 
> than a DV certificate (and the associated name).  I'd need more supporting 
> evidence to believe that.  Under what conditions could that be true?

I'm not making any claims at all about the ease with which one can get 
different types of certificates. I'm only stating that it's possible to get 
IP-based certificates, and people do, and thus it's possible to have a 
client-facing server that has an IP-based certificate.



> On Apr 20, 2021, at 7:10 PM, Martin Thomson  wrote:
> 
> On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote:
>>> I'm not sure what you are implying might be impossible.  Are you suggesting 
>>> that it might be impossible to get a name for which you could get a 
>>> certificate?
>> 
>> No. I'm implying that if we don't allow clients to authenticate 
>> client-facing servers with an IP-based certificate, ECH won't be 
>> possible in cases where the client-facing server doesn't have a name.
> 
> That in turn implies that getting an IP-based certificate might be easier 
> than a DV certificate (and the associated name).  I'd need more supporting 
> evidence to believe that.  Under what conditions could that be true?

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

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

[Carrick Bartle]

> In general, I'd prefer we get ECH deployed for some major use
> cases and not try fill in every possible niche at this point.

That's fine with me.


> On Apr 20, 2021, at 7:03 PM, Stephen Farrell  
> wrote:
> 
> 
> Hiya,
> 
> To answer Chris' initial question: I can't currently think of
> a real use-case where the client would need to authenticate
> an IP address for a client-facing server in the event that
> ECH decryption has been tried and failed.
> 
> And, I very much sympathise with Martin's goal of simplifying
> if we can. (E.g. leave the public_name as-is and as we've got
> implemented, but drop the extensions field entirely - I don't
> think there's a shortage of code points for new extensions if
> the first ECH one doesn't quite do what's needed.)
> 
> But I'm likely not the right person to ask - I'd guess that
> the people who might have a use-case for this are smaller
> hosters where the default listener on 443 is very minimal. I
> don't know how common those are, but I'd suspect they are
> fairly rare. And likely those with certs that have the
> exactly right IP address are even rarer.
> 
> On 21/04/2021 02:48, Carrick Bartle wrote:
>>> I'm not sure what you are implying might be impossible.  Are you
>>> suggesting that it might be impossible to get a name for which you
>>> could get a certificate?
>> No. I'm implying that if we don't allow clients to authenticate
>> client-facing servers with an IP-based certificate, ECH won't be
>> possible in cases where the client-facing server doesn't have a
>> name.
> 
> In general, I'd prefer we get ECH deployed for some major use
> cases and not try fill in every possible niche at this point.
> ISTM the overall win here is that we end up with ECH working
> in many cases, but don't need all cases. And there's a danger
> that we get zero cases if we make it too complex.
> 
> Cheers,
> 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] Authenticating the client-facing server with an IP-based certificate

[Carrick Bartle]

> I'm not sure what you are implying might be impossible.  Are you suggesting 
> that it might be impossible to get a name for which you could get a 
> certificate?

No. I'm implying that if we don't allow clients to authenticate client-facing 
servers with an IP-based certificate, ECH won't be possible in cases where the 
client-facing server doesn't have a name.


> On Apr 20, 2021, at 6:40 PM, Martin Thomson  wrote:
> 
> On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote:
>> This does sound unusual. That said, if this sort of set-up is possible 
>> (which presumably it is), it seems unfortunate to make ECH impossible 
>> in that scenario.
> 
> I'm not sure what you are implying might be impossible.  Are you suggesting 
> that it might be impossible to get a name for which you could get a 
> certificate?  If that could be shown to be impossible (or even just quite 
> hard) under some reasonable set of conditions, then I might change my 
> position.

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

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

[Carrick Bartle]

> we're talking about a host that fronts for multiple different names, so I'm 
> finding it hard to imagine how finding a name usable for this purpose would 
> be challenging.

This does sound unusual. That said, if this sort of set-up is possible (which 
presumably it is), it seems unfortunate to make ECH impossible in that scenario.



> On Apr 20, 2021, at 6:00 PM, Martin Thomson  wrote:
> 
> On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote:
>> Taking a step back, it would be great if we could reach consensus on 
>> whether or not this is a use case we actually want to solve. 
> 
> The Web currently recognizes IP certificates.  The specs, thanks RFC 6125, 
> largely missed this, but we're fixing that.  ACME has RFC 8738 and the latest 
> HTTP(S) spec finally defines validation for an IP-based reference identity.
> 
> All that said, IP certificates are naturally a feature with narrow 
> applicability.  For something like ECH fallback, which should be rare, we 
> benefit more from reduced options and simplicity than we do by enabling niche 
> features.  Adding a dependency on a rarely used feature, optional or not, 
> only increases the risk profile.  And complexity.
> 
> So I don't think we should support different anything other than a domain 
> name for ECH fallback.
> 
> If someone could demonstrate that it would be an undue imposition to require 
> a client-facing server to use a domain name, then I would happily concede the 
> point.  As it is, we're talking about a host that fronts for multiple 
> different names, so I'm finding it hard to imagine how finding a name usable 
> for this purpose would be challenging.
> 
> ___
> 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] Don't Split HelloRetryRequest

[Carrick Bartle]

> I absolutely agree both that we seem to be almost
> happily adding complexity 

I don't think you have to assume bad intent (or negligence). Several people 
brought up valid concerns and we're trying to address them.

> On Apr 1, 2021, at 4:46 AM, Stephen Farrell  wrote:
> 
> 
> I'm not sure I agree with all of Martin's remarks below,
> but I absolutely agree both that we seem to be almost
> happily adding complexity and that that's a bad plan.
> 
> S.
> 
> On 01/04/2021 02:57, Martin Thomson wrote:
>> I just reviewed the proposal to split HelloRetryRequest into outer and 
>> (encrypted) inner.
>> https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files
>> I'm strongly opposed to taking the change.  It complicates the design 
>> greatly and unnecessarily.
>> The existing design has some flaws, but they can be fixed more elegantly 
>> than this.
>> (Apologies if this seems a little long.  I'm writing down every possible 
>> argument I can think of, because I can't guarantee that I will be coherent 
>> at the meeting.)
>> # HelloRetryRequest Has a Narrow Purpose
>> Let's first address the key question of what HelloRetryRequest exists to do. 
>>  It exists to ensure that the client and server are able to jointly agree on 
>> keys to use for the remainder of the handshake.  This is a very narrow scope.
>> Furthermore, the particulars of key agreement are public.  This is important 
>> as we can also say that all hidden servers need to use the same 
>> configuration as it relates to cipher suites, key exchange, and related 
>> parameters, as the results of negotiation are sent in the clear in the 
>> ServerHello.
>> My claim here is that there is no value in protecting any parameter that 
>> might change in response to HelloRetryRequest.
>> # Don't Seek Complexity
>> It is entirely possible to imagine scenarios where an inner ClientHello has 
>> different preferences from an outer ClientHello.  While in theory we can 
>> construct a design that would support that (the pull request does this well 
>> enough), to do so only serves to increase complexity.  It does not address 
>> any real use case or problem that I'm aware of.
>> If we allow for the client to provide different values in inner and outer 
>> ClientHello messages, then the current design means that the client is faced 
>> with some ambiguity about which of the two messages a HelloRetryRequest 
>> applies to.  If we try to create an indicator, then that leaks.
>> We could solve the problem by making the protocol more complex.  Or we could 
>> avoid it.
>> This problem is entirely avoidable.
>> # Matching Inner and Outer Values
>> When we get right down to it, there are a very small number of things that 
>> truly change in response to HelloRetryRequest.  And all of these changes are 
>> to values that do not need confidentiality protection.
>> The draft lists three fields that change: ciphersuites, key_share, and 
>> version.  From my perspective, changing cipher suites, supported groups, or 
>> versions would be a big mistake.  So what changes is even more limited.  
>> Just the shares in key_share.
>> On this basis, a client that offers cipher suites, groups, versions, and key 
>> shares that are identical in both inner and outer ClientHello messages will 
>> always receive a HelloRetryRequest that applies equally to both messages.
>> The only adjustment that is acceptable with respect to these fields being 
>> identical is the addition of TLS 1.2-only options to the outer ClientHello 
>> (or the removal of the same from the inner ClientHello if you prefer it that 
>> way around).  This is a fine optimization on the basis that accepting ECH 
>> represents a commitment to support TLS 1.3 (or higher).  But it is really 
>> just an optimization (the draft makes this mandatory, which is silly).  The 
>> client can therefore remove options from the inner ClientHello only if it is 
>> impossible to select them with TLS 1.3 or higher.
>> For new extensions, if they define a means of adjustment or correction via 
>> HelloRetryRequest (there is currently just one: password_salt, which I 
>> haven't examined), then they too need to follow this restriction.   It's not 
>> an onerous one.
>> Follow this simple constraint and HelloRetryRequest will always apply 
>> equally to both inner and outer ClientHello and everything works.  
>> Conveniently, this is more or less exactly what the current draft says.  
>> Almost.
>> The draft currently allows inner and outer ClientHello to have different 
>> types of key share.  The way it handles this is terrible: it recommends 
>> breaking the transcript.  To me, that seems like it would only serve to open 
>> the protocol up to downgrade attack.
>> Incidentally, I don't see a problem with having a different key share 
>> *value* in inner and outer ClientHello.  There's no point in doing that 
>> unless you believe that these values leak information (they really 
>> shouldn't), but it wouldn't break this model if a 

Re: [TLS] draft-les-white-tls-preferred-pronouns

[Carrick Bartle]

Thank you!

> On Apr 1, 2021, at 11:13 AM, Lars Eggert  wrote:
> 
> The Internet Engineering Task Force (IETF) prides itself on its open 
> philosophy, where anyone can submit a proposal or comment on work in 
> progress, regardless of financial resources, industry credentials, race, 
> gender, sexual orientation, or national origin, without any review by the 
> organization. Regrettably, sometimes individuals abuse that openness by 
> submitting texts that are disrespectful of others, in violation of the IETF 
> Code of Conduct [1] and anti-harassment policy [2].
> 
> On 1 April 2021, there were two examples of anonymous proposals that were 
> both racist and deeply disrespectful, thus violating policy. The Internet 
> Engineering Steering Group (IESG) has accordingly removed these documents 
> from the IETF website.
> 
> Lars Eggert
> IETF Chair, on behalf of the IESG
> 
> [1] https://www.rfc-editor.org/rfc/rfc7154.html
> [2] https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/
> 
> ___
> 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] Solving HRR woes in ECH

[Carrick Bartle]

That sounds cool.

> On Mar 25, 2021, at 6:28 PM, Nick Sullivan 
>  wrote:
> 
> Hi Chris,
> 
> HRR in ECH does seem challenging. This may be tangential to the PR you 
> linked, but there may be a way to reduce the likelihood of HRR by moving even 
> more of the handshake negotiation into DNS. The HTTPS RR is already used for 
> some types of negotiation (ALPN and ECH key), so why can't it be extended 
> further to advertise to the client what the server is willing to support for 
> cryptographic negotiations?
> 
> For example, the HTTPS record could additionally contain the server's 
> supported supported_groups and cipher_suites. With this information, a client 
> could know which key_share extensions a server is likely to accept and adjust 
> its clienthello accordingly. A client who typically sends two key_shares 
> (P256 and x25519) for maximal compatibility could then reduce the size of its 
> client hello (no need to send redundant key_shares) or even prevent an HRR 
> flow altogether in the case that the default key_shares or cipher_suites are 
> not supported by the server.
> 
> This tweak wouldn't remove the need for HRR completely -- it could be 
> necessary when changing server configuration, for example -- but it could 
> remove the need for HRR in the common case.
> 
> Nick
> 
> On Thu, Mar 25, 2021 at 8:05 PM Christopher Patton 
>  > wrote:
> Hi all, 
> 
> One of the open issues for ECH is how it interacts with HelloRetryRequest 
> (HRR). The central difficulty is that a client may advertise different 
> preferences for HRR-sensitive parameters in the ClientHelloInner and 
> ClientHelloOuter. And because the HRR path has no explicit signal of which 
> ClientHello was used, the client may not be able to know how to respond. The 
> following PR solves this problem by adding to HRR an explicit signal of which 
> ClientHello was used:
> https://github.com/tlswg/draft-ietf-tls-esni/pull/407 
> 
> 
> The design was originally proposed by David Benjamin in the issue referenced 
> by the PR. Along the way, It also solves a handful of other HRR issues that 
> have been identified.
> 
> One consequence of this particular solution is that real ECH usage "sticks 
> out" if the server responds with an HRR. In particular, signaling which 
> ClientHello was used also signals whether ECH was accepted. However, the 
> solution is designed to mitigate "don't stick out" attacks that attempt to 
> trigger the HRR codepath by fiddling with bits on the wire. The distinguisher 
> only arises when HRR happens organically.
> 
> Feedback is appreciated!
> 
> Best,
> Chris P.
> ___
> 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] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

> Which is not nearly as strong as "MUST NOT", which is what I take
> deprecation to mean.  Am I wrong about the intended meaning of
> "deprecation"?

That's my understanding as well.


> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni  wrote:
> 
> On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:
> 
>>> Because there are still many TLS (non-web) implementations that don't
>>> do ECDHE.
>> 
>> I'm confused: if those implementations don't do ECDHE, what's wrong
>> with prohibiting the way it's used?
> 
> The proposal on the table is to deprecate FFDHE.  If the software stack
> has no ECDHE, and only has FFDHE, it would then have to resort to RSA
> key exchange.
> 
>>>   * In practice security improves more when you raise the ceiling,
>>> rather the floor.
>> 
>> This sort of suggests that we should never deprecate anything, ever, no?
> 
> No, rather it suggests that *before* we deprecate, we first work to get
> everyone to use stronger options, and then, crisis situations aside,
> wait for the long tail to effectively peter out.  Then deprecate, once
> it is clear that it is mostly a formality.
> 
> The difficult question is how to handle situations where the long tail
> is mostly invisible to the IETF community, i.e. happens on isolated
> networks, that use (and may be audited against) our standards, but don't
> show up in Internet surveys, ...  It may then be hard to know when to
> declare to declare victory.  I don't have a good answer for that.
> This is where Peter Gutmann et. al., may be able to help.
> 
> Deprecation is not always easy, and we don't always the desired outcome.
> 
> I hear that in Germany operators of some services are expected to
> operate their systems in accordance with "state of the art" practices
> (I guess BCP).  This may allow a distinction between "tolerable" and
> "best practice", where things we might deprecate would no longer be
> "best practice", but are still within the standard, and expected
> to interoperate if implemented by both (all relevant) parties.
> 
> So short of deprecation, one might say that the legacy algorithms:
> 
>* Are not recommended.
>* Can't be expected to be widely implemented
>* Should only be used when the preferred choices
>  are not available.
> 
> Which is not nearly as strong as "MUST NOT", which is what I take
> deprecation to mean.  Am I wrong about the intended meaning of
> "deprecation"?
> 
> -- 
>   Viktor.
> 
> ___
> 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] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

Oh, never mind, presumably you're referring to the proposal in this thread.


> On Mar 9, 2021, at 4:47 PM, Carrick Bartle 
>  wrote:
> 
>> The proposal on the table is to deprecate FFDHE. 
> 
> Sorry, the title of the document is incorrect and will be changed. The actual 
> proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key 
> reuse for FFDHE.
> 
> 
>> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni  wrote:
>> 
>> On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:
>> 
>>>> Because there are still many TLS (non-web) implementations that don't
>>>> do ECDHE.
>>> 
>>> I'm confused: if those implementations don't do ECDHE, what's wrong
>>> with prohibiting the way it's used?
>> 
>> The proposal on the table is to deprecate FFDHE.  If the software stack
>> has no ECDHE, and only has FFDHE, it would then have to resort to RSA
>> key exchange.
>> 
>>>>  * In practice security improves more when you raise the ceiling,
>>>>rather the floor.
>>> 
>>> This sort of suggests that we should never deprecate anything, ever, no?
>> 
>> No, rather it suggests that *before* we deprecate, we first work to get
>> everyone to use stronger options, and then, crisis situations aside,
>> wait for the long tail to effectively peter out.  Then deprecate, once
>> it is clear that it is mostly a formality.
>> 
>> The difficult question is how to handle situations where the long tail
>> is mostly invisible to the IETF community, i.e. happens on isolated
>> networks, that use (and may be audited against) our standards, but don't
>> show up in Internet surveys, ...  It may then be hard to know when to
>> declare to declare victory.  I don't have a good answer for that.
>> This is where Peter Gutmann et. al., may be able to help.
>> 
>> Deprecation is not always easy, and we don't always the desired outcome.
>> 
>> I hear that in Germany operators of some services are expected to
>> operate their systems in accordance with "state of the art" practices
>> (I guess BCP).  This may allow a distinction between "tolerable" and
>> "best practice", where things we might deprecate would no longer be
>> "best practice", but are still within the standard, and expected
>> to interoperate if implemented by both (all relevant) parties.
>> 
>> So short of deprecation, one might say that the legacy algorithms:
>> 
>>   * Are not recommended.
>>   * Can't be expected to be widely implemented
>>   * Should only be used when the preferred choices
>> are not available.
>> 
>> Which is not nearly as strong as "MUST NOT", which is what I take
>> deprecation to mean.  Am I wrong about the intended meaning of
>> "deprecation"?
>> 
>> -- 
>>  Viktor.
>> 
>> ___
>> 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] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

> The proposal on the table is to deprecate FFDHE. 

Sorry, the title of the document is incorrect and will be changed. The actual 
proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key reuse 
for FFDHE.


> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni  wrote:
> 
> On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:
> 
>>> Because there are still many TLS (non-web) implementations that don't
>>> do ECDHE.
>> 
>> I'm confused: if those implementations don't do ECDHE, what's wrong
>> with prohibiting the way it's used?
> 
> The proposal on the table is to deprecate FFDHE.  If the software stack
> has no ECDHE, and only has FFDHE, it would then have to resort to RSA
> key exchange.
> 
>>>   * In practice security improves more when you raise the ceiling,
>>> rather the floor.
>> 
>> This sort of suggests that we should never deprecate anything, ever, no?
> 
> No, rather it suggests that *before* we deprecate, we first work to get
> everyone to use stronger options, and then, crisis situations aside,
> wait for the long tail to effectively peter out.  Then deprecate, once
> it is clear that it is mostly a formality.
> 
> The difficult question is how to handle situations where the long tail
> is mostly invisible to the IETF community, i.e. happens on isolated
> networks, that use (and may be audited against) our standards, but don't
> show up in Internet surveys, ...  It may then be hard to know when to
> declare to declare victory.  I don't have a good answer for that.
> This is where Peter Gutmann et. al., may be able to help.
> 
> Deprecation is not always easy, and we don't always the desired outcome.
> 
> I hear that in Germany operators of some services are expected to
> operate their systems in accordance with "state of the art" practices
> (I guess BCP).  This may allow a distinction between "tolerable" and
> "best practice", where things we might deprecate would no longer be
> "best practice", but are still within the standard, and expected
> to interoperate if implemented by both (all relevant) parties.
> 
> So short of deprecation, one might say that the legacy algorithms:
> 
>* Are not recommended.
>* Can't be expected to be widely implemented
>* Should only be used when the preferred choices
>  are not available.
> 
> Which is not nearly as strong as "MUST NOT", which is what I take
> deprecation to mean.  Am I wrong about the intended meaning of
> "deprecation"?
> 
> -- 
>   Viktor.
> 
> ___
> 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] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

>>> I think the blanket prohibition of reuse of ECDHE keys is maybe not
>>> really justified.
>> 
>> Why is that?
> 
> Because there are still many TLS (non-web) implementations that don't
> do ECDHE.

I'm confused: if those implementations don't do ECDHE, what's wrong with 
prohibiting the way it's used?

>* In practice security improves more when you raise the ceiling,
>  rather the floor.

This sort of suggests that we should never deprecate anything, ever, no?



> On Mar 8, 2021, at 7:57 PM, Viktor Dukhovni  wrote:
> 
> On Mon, Mar 08, 2021 at 07:08:31PM -0800, Carrick Bartle wrote:
> 
>>> I think the blanket prohibition of reuse of ECDHE keys is maybe not
>>> really justified.
>> 
>> Why is that?
> 
> Because there are still many TLS (non-web) implementations that don't
> do ECDHE.
> 
> Is there a credible active MiTM attack that can cause a server and
> client both capable of ECDHE to use FFDHE or RSA key exchange?
> 
> If so, a properly scoped (to the web or the public Internet, ...)
> deprecation of FFDHE and RSA key exchange is then justified.
> 
> If not, then I am cursed to ever repeat a key message of RFC7435:
> 
>* In practice security improves more when you raise the ceiling,
>  rather the floor.
> 
>* If you set the bar too high, users will resort to less secure,
>  but more accessible technologies.
> 
> If your basic protocol is basically sound (has downgrade-resistant
> feature negotiation) then deprecation can be counter-productive in
> the short to medium term, so long as a non-negligible fraction of
> the installed base is then no longer tall enough to take the ride.
> 
> Therefore, a better approach may be to recommend that for key
> exchange ECDHE should be prioritised ahead of EDH and RSA.
> 
> The effort may also be largely redundant, affecting only the
> deployments that are likely to end up resorting to suboptimal
> choices.
> 
> Below, for example, is the default TLS 1.2 ordered cipherlist for
> OpenSSL 1.1.1.  All other parameters being equal, in each group
> the order is kECDHE+aECDSA, kECDHE+aRSA and finally kDHE+aRSA:
> 
>  ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AESGCM(256) 
> Mac=AEAD
>  ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(256) 
> Mac=AEAD
>  DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA  Enc=AESGCM(256) 
> Mac=AEAD
> 
>  ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH   Au=ECDSA 
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
>  ECDHE-RSA-CHACHA20-POLY1305   TLSv1.2 Kx=ECDH   Au=RSA  
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
>  DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA  
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> 
>  ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AESGCM(128) 
> Mac=AEAD
>  ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(128) 
> Mac=AEAD
>  DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA  Enc=AESGCM(128) 
> Mac=AEAD
> 
>  ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AES(256)  
> Mac=SHA384
>  ECDHE-RSA-AES256-SHA384   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(256)  
> Mac=SHA384
>  DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA  Enc=AES(256)  
> Mac=SHA256
> 
>  ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH   Au=ECDSA Enc=AES(128)  
> Mac=SHA256
>  ECDHE-RSA-AES128-SHA256   TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(128)  
> Mac=SHA256
>  DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA  Enc=AES(128)  
> Mac=SHA256
> 
>  ECDHE-ECDSA-AES256-SHATLSv1 Kx=ECDH Au=ECDSA Enc=AES(256)  
> Mac=SHA1
>  ECDHE-RSA-AES256-SHA  TLSv1 Kx=ECDH Au=RSA  Enc=AES(256)  
> Mac=SHA1
>  DHE-RSA-AES256-SHASSLv3 Kx=DH   Au=RSA  Enc=AES(256)  
> Mac=SHA1
> 
>  ECDHE-ECDSA-AES128-SHATLSv1 Kx=ECDH Au=ECDSA Enc=AES(128)  
> Mac=SHA1
>  ECDHE-RSA-AES128-SHA  TLSv1 Kx=ECDH Au=RSA  Enc=AES(128)  
> Mac=SHA1
>  DHE-RSA-AES128-SHASSLv3 Kx=DH   Au=RSA  Enc=AES(128)  
> Mac=SHA1
> 
>  -- Finally, last resort kRSA
>  AES256-GCM-SHA384 TLSv1.2 Kx=RSAAu=RSA  Enc=AESGCM(256) 
> Mac=AEAD
>  AES128-GCM-SHA256 TLSv1.2 Kx=RSAAu=RSA  Enc=AESGCM(128) 
> Mac=AEAD
>  AES256-SHA256 TLSv1.2 Kx=RSAAu=RSA  Enc=AES(256)  
> Mac=SHA256
>  AES128-SHA256 TLSv1.2 Kx=RSAAu=RSA  Enc=AES(128)  
> Mac=SHA256
>  AES256-SHASSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  
> Mac=SHA1
>  AES128-SHASSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  
> Mac=SHA1
> 
> There's hardly any need to goad the ecosystem to prefer ECDHE when
&

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

> I think the blanket prohibition of reuse of ECDHE keys is maybe not really 
> justified.

Why is that?

> IMO that's the part that should have deprecation of RSA cipher suites done at 
> the same time.

RSA seems to me to be too off-topic for this draft. (It also seems to me that 
RSA is still too widely used and not broken enough to merit deprecation.) If 
you think this draft requires that RSA key exchange also be deprecated, that 
could be done in a parallel draft.


> On Mar 8, 2021, at 4:23 PM, Brian Smith  wrote:
> 
> Brian Smith mailto:br...@briansmith.org>> wrote:
> It is sad that nobody is willing to discuss the obvious downsides of this 
> proposal as written, which should at least be mentioned in the security 
> considerations. Without discussing the downsides we're reducing engineering 
> to politics. If we discuss the downsides then we can substantially improve 
> the proposal.
> 
> To clarify: the RFC is about deprecating non-ephemeral cipher suites and 
> reusing keys in implementing the ephemeral cipher suites. I don't know of any 
> practical issues with the RFC as written, although I think the blanket 
> prohibition of reuse of ECDHE keys is maybe not really justified.
> 
> The proposal that I'm saying needs to be improved is the proposal of 
> deprecating the ephemeral FFDHE cipher suites at the same time. IMO that's 
> the part that should have deprecation of RSA cipher suites done at the same 
> time.
> 
> Cheers,
> Brian
> ___
> 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] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

Great, sounds good to me then.

> On Mar 8, 2021, at 11:24 AM, David Benjamin  wrote:
> 
> I guess it's a question of what the goal of this draft is. I don't 
> particularly care as long as it's self-consistent. :-)
> 
> We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*, 
> TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
> We've got the contents, which are targeting non-PFS flows, EC or FF. That is, 
> TLS_DH_*, TLS_ECDH_*, and uses of (EC)DHE that aren't actually ephemeral.
> We've got the Raccoon citation, which would suggest[*] targeting TLS_DH_* and 
> TLS_DHE_*, due to the buggy construction, and possibly also the non-PFS modes 
> of both 1.3 FFDHE and 1.2/1.3 ECDHE because key reuse is more fragile.
> 
> [*] From the conclusion of the paper: "The most straightforward mitigation 
> against the attack is to remove support for TLS-DH(E) entirely, as most major 
> client implementations have already stopped supporting them"
> 
> On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle  <mailto:cbartle...@icloud.com>> wrote:
> I'm not opposed to expanding the scope of this document to include 
> deprecating DHE. Is there a major advantage to that being its own draft?
> 
> 
> > On Mar 8, 2021, at 10:09 AM, Martin Thomson  > <mailto:m...@lowentropy.net>> wrote:
> > 
> > One thing at a time?
> > 
> > On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> >> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
> >> 
> >> - The construction is broken. The leak itself in the Raccoon attack 
> >> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
> >> of the existing code points, so any fix there would involve dropping 
> >> them.
> >> 
> >> - It lacks group negotiation, which makes it very difficult to migrate 
> >> away from small groups. At least in the web, it's already no longer 
> >> supported by most implementations.
> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
> >>  
> >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 
> >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1496639>
> >> https://weakdh.org/ <https://weakdh.org/>
> >> 
> >> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
> >>  >> <mailto:40icloud@dmarc.ietf.org>> wrote:
> >>> Agreed. I'll change the title to reflect that.
> >>> 
> >>>> On Mar 8, 2021, at 7:33 AM, Martin Thomson  >>>> <mailto:m...@lowentropy.net>> wrote:
> >>>> 
> >>>> Well overdue.  We should do this.
> >>>> 
> >>>> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to 
> >>>> match the document content.  I only see static or semi-static DH and 
> >>>> ECDH key exchange being deprecated (in the document as non-ephemeral).
> >>>> 
> >>>> ___
> >>>> TLS mailing list
> >>>> TLS@ietf.org <mailto:TLS@ietf.org>
> >>>> https://www.ietf.org/mailman/listinfo/tls 
> >>>> <https://www.ietf.org/mailman/listinfo/tls>
> >>> 
> >>> ___
> >>> TLS mailing list
> >>> TLS@ietf.org <mailto:TLS@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/tls 
> >>> <https://www.ietf.org/mailman/listinfo/tls>
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org <mailto:TLS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tls 
> > <https://www.ietf.org/mailman/listinfo/tls>
> 

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

I'm not opposed to expanding the scope of this document to include deprecating 
DHE. Is there a major advantage to that being its own draft?


> On Mar 8, 2021, at 10:09 AM, Martin Thomson  wrote:
> 
> One thing at a time?
> 
> On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
>> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
>> 
>> - The construction is broken. The leak itself in the Raccoon attack 
>> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
>> of the existing code points, so any fix there would involve dropping 
>> them.
>> 
>> - It lacks group negotiation, which makes it very difficult to migrate 
>> away from small groups. At least in the web, it's already no longer 
>> supported by most implementations.
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639
>> https://weakdh.org/
>> 
>> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
>>  wrote:
>>> Agreed. I'll change the title to reflect that.
>>> 
>>>> On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
>>>> 
>>>> Well overdue.  We should do this.
>>>> 
>>>> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match 
>>>> the document content.  I only see static or semi-static DH and ECDH key 
>>>> exchange being deprecated (in the document as non-ephemeral).
>>>> 
>>>> ___
>>>> 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Carrick Bartle]

If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a 
draft, I'll remove all mention of 1.0/1.1.


> On Mar 8, 2021, at 8:34 AM, John Mattsson 
>  wrote:
> 
> +1 for forbidding more old crap.
> 
> Lack of forward secrecy should imply at least NOT RECOMMENDED.
> 
> Does it make sense to forbid things for TLS 1.0 and TLS 1.1 when we soon have 
> an RFC forbidding use of TLS 1.0 and TLS 1.1?
> 
> Cheers,
> John
> 
> 
> -Original Message-
> From: TLS  on behalf of Martin Thomson 
> 
> Date: Monday, 8 March 2021 at 16:34
> To: "TLS@ietf.org" 
> Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
> 
> Well overdue.  We should do this.
> 
> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the 
> document content.  I only see static or semi-static DH and ECDH key exchange 
> being deprecated (in the document as non-ephemeral).
> 
> ___
> 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] Moving the ECH interop target

[Carrick Bartle]

Fine by me.

> On Feb 24, 2021, at 10:07 AM, Christopher Wood  wrote:
> 
> The WG previously decided to make draft-ietf-tls-esni-09 the official target 
> for interop. The diff between this version and the current editor's copy of 
> the draft is below:
> 
>   
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-tls-esni.txt=https://tlswg.github.io/draft-ietf-tls-esni/draft-ietf-tls-esni.txt
> 
> Given the size of the diff, and the recent update to HPKE to prepare it for 
> IRSG review, I'd like to propose that we cut -10 (when the datatracker opens) 
> and use that as the new interop target. This will resolve the moving HPKE 
> target going forward and let that part of the protocol stabilize.
> 
> What do other implementers think?
> 
> Thanks,
> Chris (no hat)
> 
> ___
> 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] [ECH] Reverting the config ID change

[Carrick Bartle]

Not if "more resistence" is still trivial.


> On Feb 17, 2021, at 9:51 AM, Jonathan Hoyland  
> wrote:
> 
> Being totally indistinguishable is probably impossible, but all else being 
> equal more resistance is better than less, no?
> 
> Regards,
> 
> Jonathan
> 
> On Wed, 17 Feb 2021 at 17:41, Carrick Bartle  <mailto:cbartle...@icloud.com>> wrote:
> Numerous ways a client can "stick out" have been identified, to the point 
> where it's trivial to block connections using real ECH, regardless of the 
> length of the config_id, which was why I thought we'd largely dropped the 
> attempt not to stick out.
> 
> 
> 
>> On Feb 17, 2021, at 8:35 AM, Jonathan Hoyland > <mailto:jonathan.hoyl...@gmail.com>> wrote:
>> 
>> I know that ECH doesn't provide security against probing attackers, but such 
>> an attacker could easily maintain a list of active keys, and drop 
>> connections using them.
>> If the key ID is very long, this would be highly effective at allowing 
>> grease ECH connections, but blocking real ECH connections.
>> 
>> An adversary using this strategy against a one byte id would have high 
>> collateral damage, but against an eight byte id would virtually none.
>> 
>> Providing some resistance to probing adversaries is a nice-to-have, even if 
>> we can't provide complete protection.
>> 
>> My preference would be for a shorter id.
>> 
>> Regards,
>> 
>> Jonathan
>> 
>> On Wed, 17 Feb 2021 at 16:25, Stephen Farrell > <mailto:stephen.farr...@cs.tcd.ie>> wrote:
>> 
>> 
>> On 17/02/2021 16:00, Eric Rescorla wrote:
>> > On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell > > <mailto:stephen.farr...@cs.tcd.ie>>
>> > wrote:
>> > 
>> >>
>> >>
>> >> On 17/02/2021 00:34, Eric Rescorla wrote:
>> >>> How is it any harder to manage a multi-octet server-chosen value than a
>> >>> single-octet server-chosen value?
>> >>
>> >> Easier for the library on the server side. If it's >1 octet
>> >> then someone will want some semantics. If ==1 then they'll
>> >> have to accept none and possible collisions so it can be
>> >> handled independently inside the library.
>> >>
>> > 
>> > The server is free to enforce 1 byte.
>> 
>> A server operator would be free to do that. The person
>> writing the code likely would not be as some server
>> operator would also be free to try impose semantics
>> on a multibyte field.
>> 
>> S.
>> 
>> 
>> > 
>> > -Ekr
>> > 
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls>
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls>
> 

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

Re: [TLS] [ECH] Reverting the config ID change

[Carrick Bartle]

Numerous ways a client can "stick out" have been identified, to the point where 
it's trivial to block connections using real ECH, regardless of the length of 
the config_id, which was why I thought we'd largely dropped the attempt not to 
stick out.



> On Feb 17, 2021, at 8:35 AM, Jonathan Hoyland  
> wrote:
> 
> I know that ECH doesn't provide security against probing attackers, but such 
> an attacker could easily maintain a list of active keys, and drop connections 
> using them.
> If the key ID is very long, this would be highly effective at allowing grease 
> ECH connections, but blocking real ECH connections.
> 
> An adversary using this strategy against a one byte id would have high 
> collateral damage, but against an eight byte id would virtually none.
> 
> Providing some resistance to probing adversaries is a nice-to-have, even if 
> we can't provide complete protection.
> 
> My preference would be for a shorter id.
> 
> Regards,
> 
> Jonathan
> 
> On Wed, 17 Feb 2021 at 16:25, Stephen Farrell  > wrote:
> 
> 
> On 17/02/2021 16:00, Eric Rescorla wrote:
> > On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell  > >
> > wrote:
> > 
> >>
> >>
> >> On 17/02/2021 00:34, Eric Rescorla wrote:
> >>> How is it any harder to manage a multi-octet server-chosen value than a
> >>> single-octet server-chosen value?
> >>
> >> Easier for the library on the server side. If it's >1 octet
> >> then someone will want some semantics. If ==1 then they'll
> >> have to accept none and possible collisions so it can be
> >> handled independently inside the library.
> >>
> > 
> > The server is free to enforce 1 byte.
> 
> A server operator would be free to do that. The person
> writing the code likely would not be as some server
> operator would also be free to try impose semantics
> on a multibyte field.
> 
> S.
> 
> 
> > 
> > -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

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

Re: [TLS] [ECH] Reverting the config ID change

[Carrick Bartle]

I see. It seems reasonable to me to leave it as a variable-length vector to 
provide flexibility. Since the best mitigation for the privacy issue, 
regardless of the length of the config_id, is to have a large anonymity set as 
described in Security and Privacy Goals, it doesn't seem like a longer 
config_id is, in all cases, a major privacy trade-off.



> On Feb 16, 2021, at 4:34 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle  <mailto:cbartle...@icloud.com>> wrote:
>>  It's not significant extra complexity to have this field bigger and it 
>> basically makes it impossible to have any structure.
> 
> What do you mean by structure? How does a byte not provide sufficient 
> "structure"?
> 
> It's not long enough to encode much. As a concrete example, what if the label 
> is actually an encrypted version of the private key? Or you have a 
> distributed generation algorithm that you don't want to synchronize?
> 
> -Ekr
> 

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

Re: [TLS] [ECH] Reverting the config ID change

[Carrick Bartle]

>  It's not significant extra complexity to have this field bigger and it 
> basically makes it impossible to have any structure.

What do you mean by structure? How does a byte not provide sufficient 
"structure"?



> On Feb 16, 2021, at 3:33 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Tue, Feb 16, 2021 at 3:01 PM Martin Thomson  > wrote:
> On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote:
> > That's true, but I'd personally prefer one tracking vector to two. This 
> > structure also better aligns with other proposed use cases for HPKE 
> > configurations. I also don't see an immediate need for flexibility in 
> > this value given that there are extensions in ECHConfigContents already.
> 
> I don't see the tracking angle as relevant here.  The only things that might 
> matter is size, collision probability (for greasing), and consistency.  Size 
> doesn't matter, because it's a handful of bytes at most; collisions matter 
> little because the cost is a resource the server is prepared to spend anyway; 
> consistency with something that can also change isn't worth much.
> 
> The primary argument I would have in support of this is YAGNI.  The number of 
> active keys should be much smaller than 256, and there's a slot for 
> extensions should that need arise.
> 
> I don't find YAGNI that persuasive in this case. It's not significant extra 
> complexity to have this field bigger and it basically makes it impossible to 
> have any structure.
> 
> -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] Call for adoption of draft-vvv-tls-cross-sni-resumption

[Carrick Bartle]

I also support adoption.



> On Dec 3, 2020, at 4:17 PM, David Schinazi  wrote:
> 
> I support adoption of draft-vvv-tls-cross-sni-resumption.
> 
> David
> 
> On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich  > wrote:
>  
> 
> Hmmm... I think it probably goes in this draft, but I'm open to being wrong.
>  
> 
> That’s okay with me.
> 
> ___
> 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] TLS WG GitHub interaction

[Carrick Bartle]

I support this proposal. GitHub offers a lot more tools for organization than 
emails do, which makes reviewing issues considerably easier.


> On Oct 21, 2020, at 3:51 PM, Christopher Wood  wrote:
> 
> RFC 8874 describes several different methods for using GitHub, ranging from 
> the lightweight "document management mode" [1] to more heavyweight "issue 
> discussion mode" [2]. Most TLS documents are hosted and worked on in GitHub, 
> though with varying levels of interaction. For example, some interact with 
> GitHub in "issue tracking mode," wherein editors primarily use GitHub for 
> tracking open issues. Others interact with GitHub in a way that resembles 
> "issue discussion mode," wherein substantive issue discussion takes place on 
> GitHub issues and consensus calls occur on the list.
> 
> This discrepancy has caused confusion in the past, especially with respect to 
> how best to stay engaged in the continued development of WG documents. 
> Moreover, with the rising rate at which other WGs and IETF participants adopt 
> GitHub for document development, especially those formed in recent years, we 
> have not made expectations for use of GitHub clear.
> 
> To that end, after observing what's been maximally productive for document 
> development in TLS and related WGs, taking into account community engagement, 
> document review support, and editor tools, we propose the following: the TLS 
> WG interact with WG documents in "issue discussion mode," following the 
> approach outlined in [3].
> 
> We'd like to hear whether folks are support or oppose this proposal. Please 
> chime in (on the list!) and share your thoughts before November 4. We'll 
> determine whether there is consensus to adopt this new approach moving 
> forward at that time.
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> [1] https://www.ietf.org/rfc/rfc8874.html#name-document-management-mode
> [2] https://www.ietf.org/rfc/rfc8874.html#name-issue-labeling-schemes
> [3] https://www.ietf.org/rfc/rfc8874.html#name-issue-discussion-mode
> 
> ___
> 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] The future of external PSK in TLS 1.3

[Carrick Bartle]

>  applications that can afford the CPU

a) Not all applications can afford the CPU
b) It's not just about CPU; there are use cases where bandwidth is also an 
issue.


> On Sep 29, 2020, at 5:29 PM, Watson Ladd  wrote:
> 
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
> mailto:u...@ll.mit.edu>> wrote:
>> 
>> I share Achim's concerns.
>> 
>> But I believe the explanations will turn out mostly useless in the real 
>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>> something "not recommended".
>> 
>> In one word: bad.
> 
> Why is PSK so necessary? There are very few devices that can't handle
> the occasional ECC operation.  The key management and forward secrecy
> issues with TLS-PSK are real. Steering applications that can afford
> the CPU away from PSK and toward hybrid modes is a good thing and why
> this registry exists imho.
> 
> 
> -- 
> Astra mortemque praestare gradatim
> 
> ___
> 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] The future of external PSK in TLS 1.3

[Carrick Bartle]

I didn't mention SCADA at all. Did you mean to address this question to Filippo 
or Peter?


> On Sep 23, 2020, at 4:49 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Carrick, 
>  
> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.
>  
> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.
>  
> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  
>  
> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?
>  
> Ciao
> Hannes
>  
> From: Carrick Bartle  
> Sent: Monday, September 21, 2020 6:19 PM
> To: Hannes Tschofenig 
> Cc: Carrick Bartle ; Filippo Valsorda 
> ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> Can you justify your reasoning? 
>  
> Which part?
>  
> 
> 
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  <mailto:hannes.tschofe...@arm.com>> wrote:
>  
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
> Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
> Cc: tls@ietf.org <mailto:tls@ietf.org>
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  <mailto:fili...@ml.filippo.io>> wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  <mailto:pgut...@cs.auckland.ac.nz>>:
> John Mattsson  <mailto:40ericsson@dmarc.ietf.org>> writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> Indeed, if the SCADA industry has a particular need, they should profile TLS 
> for use in that industry, and not require we change the recommendation for 
> the open Internet.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
>  
> 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

Re: [TLS] The future of external PSK in TLS 1.3

[Carrick Bartle]

> Can you justify your reasoning? 

Which part?


> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS  On Behalf Of Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda 
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  <mailto:fili...@ml.filippo.io>> wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  <mailto:pgut...@cs.auckland.ac.nz>>:
> John Mattsson  <mailto:40ericsson@dmarc.ietf.org>> writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> Indeed, if the SCADA industry has a particular need, they should profile TLS 
> for use in that industry, and not require we change the recommendation for 
> the open Internet.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
>  
> 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 <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Carrick Bartle]

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:
> 
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  >:
>> John Mattsson > > writes:
>> 
>> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
>> >handshake, both modes have severe privacy problems,
>> 
>> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
>> just because there's a concern for one specific environment doesn't mean it
>> should be banned for any use.  In particular, I think if a specific industry
>> has a particular concern, they should profile it for use in that industry but
>> not require that everyone else change their behaviour.
> 
> Indeed, if the SCADA industry has a particular need, they should profile TLS 
> for use in that industry, and not require we change the recommendation for 
> the open Internet.
> 
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
> 
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> 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] Review of draft-ietf-tls-external-psk-guidance-00

[Carrick Bartle]

Cool, I'll propose some text in the cases you mentioned.


> On Aug 20, 2020, at 6:10 AM, Christopher Wood  wrote:
> 
> On Wed, Aug 19, 2020, at 6:42 PM, Carrick Bartle wrote:
>> Thanks for the feedback! I've posted a bunch of PRs and issues, as 
>> you've seen. Here are my remaining comments:
>> 
>>>>> Low entropy keys are only secure against active attack if a PAKE is 
>>>> used with TLS.
>>>> Maybe cite a document that contains a recommended way of using PAKEs 
>>>> with TLS (e.g. draft-sullivan-tls-opaque-00)?
>>> 
>>> I'd rather not cite one (now), especially since that document is expired. 
>>> Perhaps we can file an issue to add a citation later on?
>> 
>> Looks like Mohit already added a more up-to-date citation.
>> 
>>> Filed: https://github.com/tlswg/external-psk-design-team/issues/36
>> 
>> Thanks, Mohit! :)
>> 
>>>>> Preventing this type of linkability is out of scope, as PSKs are 
>>>>> explicitly designed to support mutual authentication.Isn't mutual 
>>>>> authentication, in general, orthogonal to linkability? 
>>>> Certificates, for example, are encrypted in TLS 1.3, and so cannot be 
>>>> linked across connections.
>>> 
>>> This section speaks of linkability by the endpoints, not the network. Any 
>>> sort of identifier that's reused across connections can be linkable, be it 
>>> an external PSK ID or a certificate. 
>> 
>> Right, I get that. What I'm saying is that since there are solutions 
>> that can prevent that type of linkability (for instance, if a third 
>> party deals the PSKs to the server and clients, and those PSKs are 
>> never used more than once), the fact that PSKs are designed to support 
>> mutual authentication is irrelevant. (I.e., mutual authentication for 
>> one connection doesn't necessarily imply that the server knows it's 
>> talking to the same client on every connection that client makes.)
> 
> I think the preceding sentence provides the missing context:
> 
> "Specifically, servers can link successive connections that use the same 
> external PSK together. Preventing this type of linkability is out of scope, 
> as PSKs are explicitly designed to support mutual authentication."
> 
> That said, I see what you're saying. We can just drop "as PSKs are explicitly 
> designed to support mutual authentication." 
> 
>>>>> 6.1.  Provisioning Examples
>>>> This section contains a list of ways to provision PSKs, but mostly 
>>>> without any commentary or discussion. Are these methods good? Bad? Are 
>>>> there any pitfalls? If so, how can one guard against them?
>>> 
>>> It's meant to be informational without any comment on the pros and cons of 
>>> each. 
>> 
>> But the title is "*Guidance* for External PSK Usage." What is guidance 
>> if not a collection of recommendations?
> 
> This particular bit of the document describes use cases which informed the 
> guidance (recommendations) for PSK usage described elsewhere.
> 
>>>>> Identities may sometimes need to be routable, as is currently under 
>>>> discussion for EAP-TLS-PSK.
>>>> What does it mean for an identity to be "routable"? Also, EAP-TLS-PSK 
>>>> needs a citation link. I'm not sure which document it's referring to.
>>> 
>>> It might be, for example, a FQDN. Mohit understands the EAP-TLS-PSK use 
>>> case better than I do, though, so I'll let him answer. 
>> Looks like Mohit added a citation for that.
>> 
>>>>>  3.  Nodes SHOULD use external PSK importers 
>>>>> [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of 
>>>>> TLS client and server.
>>>> Why?
>>> 
>>> Because that interface exists to enable external PSKs for TLS 1.3 and 
>>> beyond. 
>> 
>> My understanding is that that interface doesn't *enable* external PSKs 
>> for 1.3, but that it just to makes it easier and less error-prone 
>> because the interface generates several PSKs--one for each hash 
>> function. Is that the case? If so, why not mention that as the 
>> rationale as to why nodes SHOULD use the importer?
> 
> That seems like a fine clarification. Do you want to propose some text?
> 
>>>>> OpenSSL and BoringSSL: Applications specify support for external PSKs 
>>>> via distinct ciphersuites.
>>>> This is not true of BoringSSL for TLS 1.3. Although the paragraph goes 
>>>> o

Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

[Carrick Bartle]

Thanks for the feedback! I've posted a bunch of PRs and issues, as you've seen. 
Here are my remaining comments:

>>> Low entropy keys are only secure against active attack if a PAKE is 
>> used with TLS.
>> Maybe cite a document that contains a recommended way of using PAKEs 
>> with TLS (e.g. draft-sullivan-tls-opaque-00)?
> 
> I'd rather not cite one (now), especially since that document is expired. 
> Perhaps we can file an issue to add a citation later on?

Looks like Mohit already added a more up-to-date citation.

> Filed: https://github.com/tlswg/external-psk-design-team/issues/36

Thanks, Mohit! :)

>>> Preventing this type of linkability is out of scope, as PSKs are explicitly 
>>> designed to support mutual authentication.
>> Isn't mutual authentication, in general, orthogonal to linkability? 
>> Certificates, for example, are encrypted in TLS 1.3, and so cannot be 
>> linked across connections.
> 
> This section speaks of linkability by the endpoints, not the network. Any 
> sort of identifier that's reused across connections can be linkable, be it an 
> external PSK ID or a certificate. 


Right, I get that. What I'm saying is that since there are solutions that can 
prevent that type of linkability (for instance, if a third party deals the PSKs 
to the server and clients, and those PSKs are never used more than once), the 
fact that PSKs are designed to support mutual authentication is irrelevant. 
(I.e., mutual authentication for one connection doesn't necessarily imply that 
the server knows it's talking to the same client on every connection that 
client makes.)

>>> 6.1.  Provisioning Examples
>> This section contains a list of ways to provision PSKs, but mostly 
>> without any commentary or discussion. Are these methods good? Bad? Are 
>> there any pitfalls? If so, how can one guard against them?
> 
> It's meant to be informational without any comment on the pros and cons of 
> each. 


But the title is "Guidance for External PSK Usage." What is guidance if not a 
collection of recommendations?

>>> Identities may sometimes need to be routable, as is currently under 
>> discussion for EAP-TLS-PSK.
>> What does it mean for an identity to be "routable"? Also, EAP-TLS-PSK 
>> needs a citation link. I'm not sure which document it's referring to.
> 
> It might be, for example, a FQDN. Mohit understands the EAP-TLS-PSK use case 
> better than I do, though, so I'll let him answer. 

Looks like Mohit added a citation for that.

>>>   3.  Nodes SHOULD use external PSK importers 
>>> [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of 
>>> TLS client and server.
>> Why?
> 
> Because that interface exists to enable external PSKs for TLS 1.3 and beyond. 


My understanding is that that interface doesn't enable external PSKs for 1.3, 
but that it just to makes it easier and less error-prone because the interface 
generates several PSKs--one for each hash function. Is that the case? If so, 
why not mention that as the rationale as to why nodes SHOULD use the importer?

>>> OpenSSL and BoringSSL: Applications specify support for external PSKs 
>> via distinct ciphersuites.
>> This is not true of BoringSSL for TLS 1.3. Although the paragraph goes 
>> on to mention "new callback functions added specifically to OpenSSL for 
>> TLS 1.3 [RFC8446] PSK support," this doesn't preclude 1.3 PSK support 
>> in BoringSSL.
> 
> We didn't want to go into version-specific details here, but yes, that's 
> right. 


Might be better to mention this particular version-specific detail here since 
otherwise this statement is misleading.

>>> some systems require the provisioning process to embed 
>> application-specific information in either PSKs or their identities.
>> Is it really a good idea to embed data in the PSK itself? Does that not 
>> diminish the entropy of the PSK? Why is it not sufficient to put that 
>> sort of information in the identity?
> 
> It is probably desirable to use the identity for this purpose since, well, 
> its application-specific identifying information. This is just commenting on 
> the state of affairs, I think.

Okay, but if this document is guidance and not just a description, shouldn't it 
also comment on whether this state of affairs is a good idea?

Carrick





> On Aug 18, 2020, at 8:26 AM, Christopher Wood  wrote:
> 
> Hi Carrick,
> 
> Sorry for the delay. Please see inline below!
> 
> On Thu, Jul 9, 2020, at 10:09 PM, Carrick Bartle wrote:
>> Isn’t the rerouting attack described in Section 4 not possible if "A" 
>> uses the SNI extension and "C" aborts the connection on mismatch? If 
>> 

Re: [TLS] Possible blocking of Encrypted SNI extension in China

[Carrick Bartle]

Weird. Thanks for the update. How are you confirming that it's blocked from 
inside-out?



> On Aug 13, 2020, at 10:30 AM, David Fifield  wrote:
> 
> On Fri, Aug 07, 2020 at 05:56:30PM -0600, David Fifield wrote:
>> Most of the functions of the Great Firewall work bidirectionally, and
>> the ESNI detection and blocking are no exception. Sending an
>> ESNI-containing ClientHello from *outside* of China to a server
>> *inside* results in temporary blocking, just the same as sending one
>> from the inside to the outside. This makes it easy to experiment with,
>> even if you don't control a host in China.
> 
> Triggering blocking from the outside no longer works. ESNI connections
> that originate inside the firewall are still blocked. This was first
> observed by GFW report, who were able to isolate the change from
> bidirectionality to unidirectional to a five-minute window: between
> 06:27 and 06:32 UTC on 2020-08-13. I tried it myself, and I confirm that
> I am not now able to trigger ESNI blocking from outside the firewall.
> https://github.com/net4people/bbs/issues/43#issuecomment-673322409
> 
> ___
> 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] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

[Carrick Bartle]

> I gtend to start with the abstract: "TLS allows
> client/server applications to communicate over the
> Internet in a way that is designed to prevent
> eavesdropping, tampering, and message forgery."


It seems clear that TLS proxies obey the letter, if not the spirit, of that 
statement.

However, it seems to me that no further discussion in the TLSWG is necessary 
given Martin's assertion that "The TLS working group has decided not to 
undertake work in this area."



> On Jul 29, 2020, at 5:06 PM, Stephen Farrell  
> wrote:
> 
> 
> Hiya,
> 
> On 30/07/2020 00:56, Eric Rescorla wrote:
>> What text in TLS do you believe terminating proxies (in either direction)
>> do not conform to?
> 
> I gtend to start with the abstract: "TLS allows
> client/server applications to communicate over the
> Internet in a way that is designed to prevent
> eavesdropping, tampering, and message forgery."
> 
> I think that text has remained through various
> iterations.
> 
> More importantly, the analyses done for tls1.3
> afaik do not consider such 3rd parties except as
> an attacker.
> 
> I'm by no means denying the fact that MITM boxen
> are deployed, but the idea that some of them are
> "conformant" and some are not seems bogus.
> 
> S.
> <0x5AB2FAF17B172BEA.asc>___
> 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] Review of draft-ietf-tls-external-psk-guidance-00

[Carrick Bartle]

Hi everyone,

A few thoughts on draft-ietf-tls-external-psk-guidance-00:

Isn’t the rerouting attack described in Section 4 not possible if "A" uses the 
SNI extension and "C" aborts the connection on mismatch? If so, it might be 
worth mentioning that as a potential mitigation (as the Selfie paper does).

> "C" has completed the handshake, ostensibly with "A".
"C" did in fact complete the handshake with "A." (Without mistaking it for some 
other endpoint or something.)

> Low entropy keys are only secure against active attack if a PAKE is used with 
> TLS.
Maybe cite a document that contains a recommended way of using PAKEs with TLS 
(e.g. draft-sullivan-tls-opaque-00)?

>  Applications should take precautions when using external PSKs to mitigate 
> these risks.
What sort of precautions should they take?

> Preventing this type of linkability is out of scope, as PSKs are explicitly 
> designed to support mutual authentication.
Isn't mutual authentication, in general, orthogonal to linkability? 
Certificates, for example, are encrypted in TLS 1.3, and so cannot be linked 
across connections.

> Below, we list some example use-cases where pair-wise external PSKs with TLS 
> have been used for authentication.
I assume "pair-wise" here means a PSK is shared between only one server and one 
client, but this the term "pair-wise" hasn't been associated with that concept 
in this document, it's not completely clear. Since "pair-wise" is used twice in 
the document, maybe define it when the concept is first introduced.

> primarily for the purposes of supporting TLS connections with fast open 
> (0-RTT data)
I've only ever heard "fast open" used in the context of TFO, which is distinct 
from (albeit similar to) 0-RTT. Using "fast open" to refer to 0-RTT sounds like 
it's conflating terms. Shouldn't "early data" be used here instead of "fast 
open"?

> In this use-case, resource-constrained IoT devices act as TLS clients and 
> share the same PSK.  The devices use this PSK for quickly establishing 
> connections with a central server.  Such a scheme ensures that the client IoT 
> devices are legitimate members of the system.
If the IoT devices only talk to a central server and not each other, why do 
they all need the same PSK?

> To perform rare system specific operations that require a higher security 
> level, the central server can request resource-intensive client 
> authentication with the usage of a certificate after successfully 
> establishing the connection with a PSK.
If you're going to authenticate with a cert, why bother preceding that with an 
authentication with a PSK?

> 6.1.  Provisioning Examples
This section contains a list of ways to provision PSKs, but mostly without any 
commentary or discussion. Are these methods good? Bad? Are there any pitfalls? 
If so, how can one guard against them?

> Moreover, PSK production lacks guidance unlike user passwords.
Isn't that precisely the point of this draft? Seems unnecessary to mention. (Or 
it might be better to move this point to the intro as a motivating factor of 
this document.)

> PSK provisioning systems are often constrained in application-specific ways.  
> For example, although one goal of provisioning is to ensure that each pair of 
> nodes has a unique key pair, some systems do not want to distribute pair-wise 
> shared keys to achieve this.
Why not? What application-specific constraint would warrant that?

> some systems require the provisioning process to embed application-specific 
> information in either PSKs or their identities.
Is it really a good idea to embed data in the PSK itself? Does that not 
diminish the entropy of the PSK? Why is it not sufficient to put that sort of 
information in the identity?

> Identities may sometimes need to be routable, as is currently under 
> discussion for EAP-TLS-PSK.
What does it mean for an identity to be "routable"? Also, EAP-TLS-PSK needs a 
citation link. I'm not sure which document it's referring to.

> Applications MUST use external PSKs that adhere to the following requirements:
I think you mean "If an application uses external PSKs, the PSKs MUST adhere to 
the following requirements." Otherwise it sounds like you're saying every 
application must use an external PSK.

> Each PSK SHOULD be derived from at least 128 bits of entropy
Recommend a particular method for doing that?

> Note that these mechanisms do not necessarily follow the same architecture as 
> the ordinary process for incorporating EPSKs described in this draft.
Where was the ordinary process for incorporating EPSKs described? Is 
"incorporating" a PSK the same as "provisioning" one? If so, several ways were 
described. What's the problem with these mechanisms (e.g. PAKE) having a 
different architecture from these ordinary processes? Are they not compatible?

>3.  Nodes SHOULD use external PSK importers 
> [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of TLS 
> client and server.
Why?

> OpenSSL 

Re: [TLS] Bikeshedding ECHO

[Carrick Bartle]

I agree that it’s misleading and potentially confusing to newcomers. 

ETCH sounds like a good alternative.


> On May 11, 2020, at 3:52 PM, Nick Harper 
>  wrote:
> 
> I see how the name ECHO can be confusing and support renaming it. All of the 
> proposed replacement names are fine with me.
> 
> On Sun, May 10, 2020 at 12:38 PM Rob Sayre  > wrote:
> 
> 
> On Sun, May 10, 2020 at 10:10 AM Benjamin Kaduk  > wrote:
> Hi Rob,
> 
> On Fri, May 08, 2020 at 10:51:00PM -0700, Rob Sayre wrote:
> > On Fri, May 8, 2020 at 3:43 PM Benjamin Kaduk  > 40akamai@dmarc.ietf.org > wrote:
> > 
> > > On Fri, May 08, 2020 at 03:38:33PM -0700, Eric Rescorla wrote:
> > > > I rather prefer ECHO.
> > >
> > > Do you have some arguments to dispel the concerns about confusion, other
> > > than
> > > your personal preference?
> > >
> > 
> > There's no confusion. I couldn't believe the issue was raised (the name
> > does not matter).
> 
> I regret to say that I completely fail to understand how you can have
> the confidence to make such a blanket statement ("there's no confusion") that
> in principle applies to all human beings, without any apparent supporting
> evidence.
> 
> I don't believe it makes sense to demand "evidence" on a completely 
> subjective issue.
> 
> As I wrote in my other email in this thread, not very many people on the 
> planet are going to need to know what this is. I haven't run into anyone 
> confused as I've worked on it, and the name was presented 6 months ago at 
> IETF 106.
>  
> If someone appears and says that they are confused, what are you
> going to tell them?
> 
> That all of the proposals collide with other meanings too (ETH, ETCH, etc). 
> This is one reason we expand acronyms on first use in IETF documents.
> 
> I don't think there's confusion here, but just preferences and annoyances. 
> The choice also doesn't matter to me.
> 
> thanks,
> Rob
> 
> 
>  
> ___
> 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] consensus call: draft-ietf-tls-ticketrequests

[Carrick Bartle]

No.

> On Mar 4, 2020, at 8:06 AM, Sean Turner  wrote:
> 
> one more time ...
> 
> All,
> 
> The purpose of this message is to help the chairs judge consensus on the way 
> forward for draft-ietf-tls-ticketrequests. The issue at hand is whether the 
> client-initiated ticket request mechanism [0] should be modified to add 
> support for ticket reuse, see [1] lines 160-214. As we see it, the way 
> forward involves either one draft or two. To that end, we would like your 
> input (YES or NO) on the following question by 2359 UTC 18 March 2020:
> 
> Must the ticket reuse use case be addresses
> in draft-ietf-tls-ticketrequests?
> 
> Full disclosure: RFC 8446 recommends against ticket reuse to help protect 
> clients from passive observers correlating connections [2]. The PR supports 
> ticket reuse for use cases for a server-to-server connection that has fixed 
> source addresses and no connection racing; if adopted the WG will need to 
> ensure that the security considerations are properly documented.
> 
> Note: There have been at least three threads on this draft [3][4][5]. Please, 
> let’s try to avoid re-litigating the points made therein.
> 
> Joe & Sean
> 
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
> [2] https://tools.ietf.org/html/rfc8446#appendix-C.4
> [3] https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/
> [4] https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/
> [5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/
> ___
> 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] consensus call: draft-ietf-tls-ticketrequests

[Carrick Bartle]

No.

> On Mar 4, 2020, at 8:06 AM, Sean Turner  wrote:
> 
> one more time ...
> 
> All,
> 
> The purpose of this message is to help the chairs judge consensus on the way 
> forward for draft-ietf-tls-ticketrequests. The issue at hand is whether the 
> client-initiated ticket request mechanism [0] should be modified to add 
> support for ticket reuse, see [1] lines 160-214. As we see it, the way 
> forward involves either one draft or two. To that end, we would like your 
> input (YES or NO) on the following question by 2359 UTC 18 March 2020:
> 
> Must the ticket reuse use case be addresses
> in draft-ietf-tls-ticketrequests?
> 
> Full disclosure: RFC 8446 recommends against ticket reuse to help protect 
> clients from passive observers correlating connections [2]. The PR supports 
> ticket reuse for use cases for a server-to-server connection that has fixed 
> source addresses and no connection racing; if adopted the WG will need to 
> ensure that the security considerations are properly documented.
> 
> Note: There have been at least three threads on this draft [3][4][5]. Please, 
> let’s try to avoid re-litigating the points made therein.
> 
> Joe & Sean
> 
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
> [2] https://tools.ietf.org/html/rfc8446#appendix-C.4
> [3] https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/
> [4] https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/
> [5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/
> ___
> 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] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Carrick Bartle]

> I agree with Watson's reasoning.

Same.


> On Feb 21, 2020, at 2:22 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> I agree with Watson's reasoning.
> 
> We know now all we need to to start working on generic mechanisms.
> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
>> On Feb 21, 2020, at 17:11, Watson Ladd 
>>  wrote:
>> 
>> On Fri, Feb 21, 2020 at 2:08 PM Stephen Farrell
>>  wrote:
>>> 
>>> 
>>> 
 On 21/02/2020 22:02, Watson Ladd wrote:
 We have already deployed widespread experiments that conducted the
 hybridization described in this draft, already have implementations
 supporting an approach similar to this draft, and that produced
 valuable input to the standardization process. It really didn't matter
 that it was SIKE or NewHope that was being hybridized, and they have
 very different characteristics.
>>> 
>>> Documented where?
>> 
>> https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
>> https://blog.cloudflare.com/the-tls-post-quantum-experiment/
>> 
>> This was also presented at the NIST standardization workshop in October of 
>> 2019.
>> 
>>> 
>>> Ta,
>>> 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

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

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

[Carrick Bartle]

Great! I'll push it on over and continue reviewing.


> On Feb 14, 2020, at 11:36 AM, Nick Sullivan 
>  wrote:
> 
> Carrick,
> 
> Thank you for reading the document and identifying an embarrassingly 
> difficult to parse motivating paragraph (with an annoying unclosed 
> parenthesis to boot). You've correctly identified the meaning it was trying 
> to convey and we'll happily review this as a PR here: 
> https://github.com/tlswg/tls-subcerts/ 
> <https://github.com/tlswg/tls-subcerts/>. I've noticed a few other 
> readability issues in the document, if you find anything else, we'll happily 
> look at those too.
> 
> Nick
> 
> On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle 
> mailto:40icloud@dmarc.ietf.org>> 
> wrote:
> TL;DR: I find it difficult to understand the second-to-last paragraph of the 
> Introduction, so I took a stab at revising it. Let me know if I should put it 
> in a pull request.
> 
> 
> This is the paragraph I'm referring to:
> 
> "These dependencies cause problems in practice. Server operators often want 
> to create short-lived certificates for servers in low- trust zones such as 
> Content Delivery Network (CDNs) or remote data centers. This allows server 
> operators to limit the exposure of keys in cases that they do not realize a 
> compromise has occurred. The risk inherent in cross-organizational 
> transactions makes it operationally infeasible to rely on an external CA for 
> such short- lived credentials. In Online Certificate Status Protocol (OCSP) 
> stapling (i.e., using the Certificate Status extension type ocsp [RFC8446], 
> if an operator chooses to talk frequently to the CA to obtain stapled 
> responses, then failure to fetch an OCSP stapled response results only in 
> degraded performance. On the other hand, failure to fetch a potentially large 
> number of short lived certificates would result in the service not being 
> available, which creates greater operational risk."
> 
> Here are my issues with it:
> 
> - I think OCSP is being brought up here as an example of a way that 
> dependence on a CA can go wrong, but that isn't really made explicit.
> 
> - I'm not sure what "only" means in "only in degraded performance." Is it 
> "the worst that can happen is just degraded performance" or "it can result 
> only in degraded performance, as opposed to better performance"? At first I 
> thought it was the latter, but after reading the subsequent sentence, I 
> realized it was probably the former.
> 
> - The use of "On the other hand" sounds like the rest of the sentence is 
> going to describe a way that failure to receive something from a CA resulted 
> in better performance, which obviously would be silly.
> 
> Taking all these points together, here's my suggestion for a revision to make 
> what I think the thrust of the paragraph is more clear:
> 
> "These dependencies cause problems in practice. Server operators often want 
> to create short-lived certificates for servers in low-trust zones such as 
> Content Delivery Network (CDNs) or remote data centers. This allows server 
> operators to limit the exposure of keys in cases where they do not realize a 
> compromise has occurred. But the risk inherent in cross-organizational 
> transactions makes it operationally infeasible to rely on an external CA for 
> such short-lived credentials. For instance, in the case of Online Certificate 
> Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension 
> type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled response. While 
> this will result in degraded performance, the ramifications of failing to 
> deliver short-lived certificates is even worse: the service that depends on 
> those certificates would go down entirely. Thus, ensuring independence from 
> CAs for short-lived certificates is critical to the uptime of a service."
> 
> 
> Carrick
> 
> 
> 
> > On Feb 5, 2020, at 12:36 PM, internet-dra...@ietf.org 
> > <mailto:internet-dra...@ietf.org> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> > 
> >Title   : Delegated Credentials for TLS
> >Authors : Richard Barnes
> >  Subodh Iyengar
> >  Nick Sullivan
> >  Eric Rescorla
> >   Filename: draft-ietf-tls-subcerts-06.txt
> >   Pages   : 15
> >   Date: 2020-02-05
> > 
> > Abstract:
> >   The org

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

[Carrick Bartle]

I also support adoption of this draft. The concerns raised in the other thread 
on this topic ([TLS] Requesting working group adoption of 
draft-stebila-tls-hybrid-design) are irrelevant within the context of adopting 
an informational draft, as it would be a "timely publication" of "general 
information [for] the Internet community."



> On Feb 13, 2020, at 9:12 AM, Joseph Salowey  wrote:
> 
> The authors of "Hybrid Key Exchange" have asked for adoption of their draft 
> as a WG item.  Please state whether you support adoption of this draft as a 
> WG item by posting a message to the TLS list by 2359 UTC 28 February 2020.  
> Please include any additional information that is helpful in understanding 
> your position.
> 
> NOTE:
> If the draft is adopted, the working group has change control over the draft 
> and the timing of its progression.  This means the document does not have to 
> be perfect as the working group can and will make changes.  Adopting the 
> draft means the working group thinks the topic is a good idea and the draft 
> is a good place to start the work.  
> 
> Thanks,
> Chris, Joe, and Sean
> 
> [0] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
> 
> 
> ___
> 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] I-D Action: draft-ietf-tls-subcerts-06.txt

[Carrick Bartle]

TL;DR: I find it difficult to understand the second-to-last paragraph of the 
Introduction, so I took a stab at revising it. Let me know if I should put it 
in a pull request.


This is the paragraph I'm referring to:

"These dependencies cause problems in practice. Server operators often want to 
create short-lived certificates for servers in low- trust zones such as Content 
Delivery Network (CDNs) or remote data centers. This allows server operators to 
limit the exposure of keys in cases that they do not realize a compromise has 
occurred. The risk inherent in cross-organizational transactions makes it 
operationally infeasible to rely on an external CA for such short- lived 
credentials. In Online Certificate Status Protocol (OCSP) stapling (i.e., using 
the Certificate Status extension type ocsp [RFC8446], if an operator chooses to 
talk frequently to the CA to obtain stapled responses, then failure to fetch an 
OCSP stapled response results only in degraded performance. On the other hand, 
failure to fetch a potentially large number of short lived certificates would 
result in the service not being available, which creates greater operational 
risk."

Here are my issues with it:

- I think OCSP is being brought up here as an example of a way that dependence 
on a CA can go wrong, but that isn't really made explicit.

- I'm not sure what "only" means in "only in degraded performance." Is it "the 
worst that can happen is just degraded performance" or "it can result only in 
degraded performance, as opposed to better performance"? At first I thought it 
was the latter, but after reading the subsequent sentence, I realized it was 
probably the former.

- The use of "On the other hand" sounds like the rest of the sentence is going 
to describe a way that failure to receive something from a CA resulted in 
better performance, which obviously would be silly.

Taking all these points together, here's my suggestion for a revision to make 
what I think the thrust of the paragraph is more clear:

"These dependencies cause problems in practice. Server operators often want to 
create short-lived certificates for servers in low-trust zones such as Content 
Delivery Network (CDNs) or remote data centers. This allows server operators to 
limit the exposure of keys in cases where they do not realize a compromise has 
occurred. But the risk inherent in cross-organizational transactions makes it 
operationally infeasible to rely on an external CA for such short-lived 
credentials. For instance, in the case of Online Certificate Status Protocol 
(OCSP) stapling (i.e., using the Certificate Status extension type ocsp 
[RFC8446]), a CA may fail to deliver OCSP stapled response. While this will 
result in degraded performance, the ramifications of failing to deliver 
short-lived certificates is even worse: the service that depends on those 
certificates would go down entirely. Thus, ensuring independence from CAs for 
short-lived certificates is critical to the uptime of a service."


Carrick



> On Feb 5, 2020, at 12:36 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
>Title   : Delegated Credentials for TLS
>Authors : Richard Barnes
>  Subodh Iyengar
>  Nick Sullivan
>  Eric Rescorla
>   Filename: draft-ietf-tls-subcerts-06.txt
>   Pages   : 15
>   Date: 2020-02-05
> 
> Abstract:
>   The organizational separation between the operator of a TLS endpoint
>   and the certification authority can create limitations.  For example,
>   the lifetime of certificates, how they may be used, and the
>   algorithms they support are ultimately determined by the
>   certification authority.  This document describes a mechanism by
>   which operators may delegate their own credentials for use in TLS,
>   without breaking compatibility with peers that do not support this
>   specification.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-06
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Carrick Bartle]

> At a high level, I think that this would be easier if it were more clearly 
> framed as *recommendations*

I'm brand new to the IETF, so please forgive me if I'm totally off base here, 
but my understanding is that Informational RFCs are explicitly not 
recommendations (let alone mandates)?

Per https://ietf.org/standards/process/informational-vs-experimental/:

'An "Informational" specification is published for the general information of 
the Internet community, and does not represent an Internet community consensus 
or recommendation.'




> On Feb 12, 2020, at 12:46 PM, Martin Thomson  wrote:
> 
> On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote:
>> We would like to request the working group adopt
>> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
>> a working group item.  We have updated the draft based on feedback
>> we've received over the past few months, including from our
>> presentations at IETF 104 and 105, and think the current version
>> represents the view of the WG to date.
> 
> I agree that we should adopt this.  I think that the draft is broadly in the 
> right shape.
> 
> Skimming through I noticed a few things that I would prefer to see eventually 
> changed, but we can do that in the working group.
> 
> At a high level, I think that this would be easier if it were more clearly 
> framed as *recommendations*, especially when it comes to the format of key 
> shares and the input secret.  One advantage of the macro-level design is that 
> the format is can be specified on a case-by-case basis.  For instance, 
> variable-length values might be length-prefixed; fixed size values don't need 
> to be.  That might avoid having to directly specify a single format. 
> 
> S 3.1 (Negotiation) suggests that a portion of the named group space be 
> reserved for this use.  I think that is a bad idea because it implies 
> semantics where none are necessary.  Picking codepoints as usual should 
> suffice; indeed, random allocation might be ideal.
> 
> The concatenation approach is definitely my preferred approach, but the 
> inconsistency between the design for key shares and secrets is curious.  This 
> design assumes that shares are length-delimited; secrets are not.  The latter 
> implies that the `ss` needs to be fixed length for a given algorithm (both 
> the PQ and classical parts), but `ct`/`pk` does not.  I can guess at why, but 
> when you can avoid the question, then I think you should.  That is, in favour 
> of more generic recommendations on structure.
> 
> To answer some of the open questions:
> 
> Larger public keys and/or ciphertexts - if we need these, we're in serious 
> trouble.  To give you an idea, even at 1k, these will start being much harder 
> to deploy.  Getting close to 64k adds all sorts of complication.  Better to 
> defer support for big messages.  Acknowledging the limitation should suffice.
> 
> Duplication of key shares - not so much an open question as something the 
> draft could acknowledge as a cost.  As previously discussed X25519 is small 
> enough that duplication doesn't hurt enough to care.
> 
> Variable-length shared secrets - see above.
> 
> Resumption - I would be supportive of policy recommendations about the 
> strength of key exchange on resumption, but as we allow straight resumption 
> without PSKs, this cannot be standardized.
> 
> Failures - If this were low enough, I'd be happy to try again.  From our 
> perspective, this isn't technically challenging, it's merely annoying. If 
> this were very low probability (as I would expect), then we might just accept 
> the loss of the occasional connection attempt.
> 
> ___
> 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