[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

[Mohit Sethi]

Hi Russ, TLS WG:

I had intended to reply on this topic a long time ago but somehow forgot.

I wonder if you have checked Noise Explorer handshake patterns: 
https://noiseexplorer.com/patterns/.


I think it covers all the different PSK-based handshake patterns: Npsk0, 
Kpsk0, Xpsk1, NNpsk0, NNpsk2, NKpsk0, NKpsk2, NXpsk2, XNpsk3, XKpsk3, 
XXpsk3, KNpsk0, KNpsk2, KKpsk0, KKpsk2, KXpsk2, INpsk1, INpsk2, IKpsk1, 
IKpsk2, IXpsk2.


Perhaps one of them reflects your scenario. Possibly KKpsk0?

Noise explorer comes with pre-written ProVerif models (including active 
and passive attacker) for each handshake pattern. As a side note, it 
also includes implementation of the handshake in Go and Rust. For 
example, on this page: https://noiseexplorer.com/patterns/KKpsk0/, you 
can find the ProVerif models of the KKpsk0 handshake patterns.


I guess there are subtle differences since Noise Framework is built for 
DH keys (and not signing keys as in TLS). Also, the certificate 
verification is not modeled and instead it is assumed that initiator and 
the responder know the long-term static key of the other party 
out-of-band. Anyhow, maybe you find it useful for progressing your draft.


--Mohit

On 5/31/24 17:44, Russ Housley wrote:

Usama:

During WG Last Call, several people asked for formal analysis,  I 
reached out to one researcher to see if thet formal analysis could be 
provided in response.  I was told the additions were too simple to get 
a published paper.  So, nothing happened.


This response says that formal analysis is needed to advance 
rfc8773bis to the Standards Track.  Other documents in other working 
groups are using RFC 8773,  They are proceeding with a downward 
reference (that needs to be called out when they reach IETF Last 
Call).  This means that people are implementing RFC 8773.


I'll gladly work with you or anyone else on the formal analysis.

Russ


On May 31, 2024, at 4:53 AM, Muhammad Usama Sardar 
 wrote:
I see much more need for analysis when it comes to the 
authentication properties of the PSK (psk/cert combination), 
whereas the secrecy (assuming authentication is a non-goal) is much 
more straightforward.


Who will perform this analysis?  I asked a researcher to perform 
such an analysis, and the response was that it is too simple to get 
a paper.  Now waht?


Russ, if you absolutely find no one, I will be happy to work on it 
over the weekends (so it will be slow). Also to clarify, I prefer to 
work with ProVerif because in my initial experiments, ProVerif was 
always way faster than Tamarin.
For the authentication analysis, I think here a Tamarin-like 
analysis might be useful for checking undesirable interactions; 
for example, could anything go wrong if a single PSK is used both 
as a traditional PSK but also as an external PSK?


Here is why I would like to see at least name of the panelist who 
wrote this. If it is Cas, it makes perfect sense to me. If it is 
someone else, I would like to know why he would prefer to recommend 
Tamarin over ProVerif. What exactly is missing in ProVerif that would 
make it unsuitable for this analysis? Or is it some usability issue?


Best Regards,

Usama




___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Mohit Sethi]

Hi Jonathan, all,

Thank you for explaining why you think client_certificate_type extension 
is unsuitable. And apologies if you had also explained this earlier. I 
somehow don't remember seeing a response to my previous comment about 
the possibility of using the client_certificate_type extension 
(https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/).


Thank you for referring to the text in RFC 7250. However, if we look at 
Section 4.4.2 of RFC8446 
(https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2); it has 
the following:



If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not
negotiated in EncryptedExtensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains a DER-encoded X.509
certificate.


At least to me, the part on "or the x.509 certificate type was 
negotiated" implies that the client_certificate_type and 
server_certificate_type extensions can indeed be used to negotiate the 
usage of x.509 certificate type.


I certainly find the approach of using the client_certificate_type 
extension better than an mTLS flag. Maybe initially the extension was 
predominantly designed for use with RPKs, but I think the extension is 
well-suited to indicate the availability of an x.509 certificate on the 
client. Besides, mutual authentication (mTLS) is not exclusive to 
certificates. It is perfectly possible to have mutual authentication 
with RPKs and with PSKs.


--Mohit

PS: Regardless of how the adoption call ends and which mechanism we 
pick, I do think a mechanism for a TLS client to solicit a 
CertificateRequest from a TLS server is needed. Based on the discussion 
thus far, I still prefer using the client_certificate_type extension.


PPS: Not sure if it is necessary or the right place, but RFC8446bis 
could clarify the usage of the client_certificate_type extension for 
soliciting mutual authentication. I'd be happy to submit a pull request.


On 4/4/24 19:11, Jonathan Hoyland wrote:

Hi Dennis,

RFC 7250 Section 4.1 says:
If the client has no remaining certificate types to send in
the client hello, other than the default X.509 type, it MUST omit the
client_certificate_type extension in the client hello.
That seems to explicitly exclude sending the single entry 0 to me.
Regards,
Jonathan


On Thu, 4 Apr 2024, 16:43 Dennis Jackson, 
 wrote:


Hi Jonathan,

My reading of RFC 7250 is the same as Mohits. Although the RFC
talks about raw public keys and a new codepoint for them, it is
building on RFC 6091 which defined a similar extension and the
X509 codepoint.

It seems fine for you to send the client_certificate_type
extension with the single entry 0 (X509). You also have the option
of using a value assigned for private use (224 and up) for your
specific use case of indicating a search engine crawler willing to
provide a client cert.

Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:

Hi all,

Thanks for the feedback here.

With respect to RFC 7250, as I mentioned earlier on list, there
seen to be two issues. First it changes the semantics of the
extension slightly, and second the RFC explicitly excludes x.509
certs.

IIUC the semantics of the extension are "I have a weird client
cert", not "I have a client cert".

With respect to whether this needs to be a working group item,
I'm not particularly averse to this being an independent document
if that's where the WG thinks it should go.
In my opinion, however, there are two things that it would be
good to get input from the TLS WG on.

One, this is a change from all previous versions of TLS in which
the client cannot induce auth, does enabling this break anyone's
assumptions?

Two, I'd like a low flag number because it saves bytes on the
wire, but there is a discussion to be had as to how common this
flag will be versus other flags.
(Non-attack) Bot traffic is very common, but it's not the
majority of traffic by any means.

Regards,

Jonathan



On Thu, 4 Apr 2024, 01:17 Christopher Patton,
 wrote:

It would be great to here from Jonathan (the author) if RFC
7250 is already sufficient for this use case.

    On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

Please see my earlier comment regarding this draft:

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

<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2Fg3tImSVXO8AEmPH1UlwRB1c1TLs%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189262944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn

Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Mohit Sethi]

Please see my earlier comment regarding this draft: 
https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/


In summary: the functionality of this draft is already achievable by 
using the client_certificate_type extension defined in RFC 7250: 
https://datatracker.ietf.org/doc/html/rfc7250 with certificate type 
value = 0: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.


The table in section 4.2 of RFC8446 even mentions that the extension can 
be included in the ClientHello: 
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby 
ensuring that the server sends a CertificateRequest message in response 
to the ClientHello received.


OpenSSL already implements this extension since it was needed for 
support raw public keys (RPKs).


As stated earlier: if it is indeed the case that the 
client_certificate_type extension is suitable for the use-case, then 
perhaps it is preferable to not have a separate flag. Otherwise, it 
would make the state machine at the server more complicated (for 
example: handling a ClientHello with both the mTLS flag and the 
client_certificate_type extension.


Therefore, like Ekr, I am mildly negative on adopting this document but 
for different reasons.


--Mohit

On 4/3/24 00:52, Sean Turner wrote:

At the IETF 119 TLS session there was some interest in the mTLS Flag I-D 
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0);
 also, see previous list discussions at [0]. This message is to judge consensus on whether 
there is sufficient support to adopt this I-D.  If you support adoption and are willing to 
review and contribute text, please send a message to the list.  If you do not support 
adoption of this I-D, please send a message to the list and indicate why.  This call will 
close on 16 April 2024.

Thanks,
Deirdre, Joe, and Sean

[0] 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D=0
___
TLS mailing list
TLS@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D=0


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

Re: [TLS] Request mTLS Flag

[Mohit Sethi]

Hi TLSWG,

I have read draft-jhoyla-req-mtls-flag-00 and the ensuing mailing list 
discussion. I also watched the recording from IETF 118. I fully under 
the use-case where trusted client bots need a mechanism to indicate to 
the server that mutual certificate based authentication is desired.


Unless I am mistaken, it has probably slipped under the radar of the WG 
that this indication is already achievable by using the 
client_certificate_type extension defined in RFC 7250: 
https://datatracker.ietf.org/doc/html/rfc7250 with certificate type 
value = 0: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.


The table in section 4.2 of RFC8446 even mentions that the extension can 
be included in the ClientHello: 
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby 
ensuring that the server sends a CertificateRequest message in response 
to the ClientHello received.


If it is indeed the case that the client_certificate_type extension is 
suitable for the use-case, then perhaps it is preferable to not have a 
separate flag. Otherwise, it would make the state machine at the server 
more complicated (for example: handling a ClientHello with both the mTLS 
flag and the client_certificate_type extension).


--Mohit

On 10/23/23 18:22, Jonathan Hoyland wrote:


Hey TLSWG,


I've just posted a new draft 
that 
defines a TLS Flag 
that 
provides a hint to the server that the client supports mTLS / is 
configured with a client certificate.



Usually the server has no way to know in advance whether a given 
inbound connection is from a client with a certificate. If the server 
unexpectedly requests a certificate from a human user, most users 
wouldn’t know what to do. To avoid this many servers never send the 
CertificateRequest message in the server’s first flight, or set up 
dedicated endpoints used only by bots. If client authentication is 
necessary it can be negotiated later using a higher layer either 
through post-handshake auth or with an Exported Authenticator, but 
both of those options add round trips to the connection.



At Cloudflare we’re exploring ways to quickly identify clients. Having 
an explicit signal from the client that it has an mTLS certificate on 
offer reduces round-trips to find out, avoids unnecessarily probing 
clients that have no certificate, etc. I think this would be an ideal 
use case for the TLS Flags extension.



I have a pair of interoperable implementations (one based on boringssl 
and one based on Go TLS) which I plan to open source before Prague. 
Obviously these include implementations of the TLS Flags extension, 
which hopefully will help drive that work forward too.



Regards,


Jonathan


___
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] [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Mohit Sethi M]

Hi all,

I have now read both the papers. I am not sure the attacks in [2] are anymore 
possible:

- The first attack described in section 4.1.1 shows that an EAP-Success leads 
to an unconditional transition to the Authenticated state irrespective of the 
current state. However, I am not sure this is the case anymore as RFC 4137 
(https://tools.ietf.org/html/rfc4137#appendix-A.1) now says :

 |+--
 |  rxSuccess &&  |
 |  (reqId == lastId) &&  |   SUCCESS
 |   (decision != FAIL)   |
 |+--

The peer cannot simply transition to SUCCESS state as the decision is 
initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after 
the peer decides that the server has sufficiently been authenticated (for EAP 
methods with mutual authentication).

- The second attack described in section 4.2 relies on the adversary sending a 
disassociate management frame and then uses the MAC address of the 
authenticated supplicant to gain network access. This again should not work as 
a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is 
followed by 4-way handshake after which there is per packet authenticity and 
integrity (with Key Confirmation Key). The attacker cannot gain network access 
without knowing the PMK (derived from the MSK) and performing the 4-way 
handshake.

The attacks in [1] are not specific to EAP. The attacks relate to Denial of 
Service (DoS) by injecting spoofed alerts in TLS. John has suggested the 
following text for the draft (which I think is sufficient):

Protected TLS Error alerts are protected failure result indications and enables 
the EAP-TLS peer and EAP-TLS server to determine that the failure result was 
not spoofed by an attacker. Protected failure result indications provide 
integrity protection and replay but MAY be unauthenticated. Protected failure 
result does not significantly improve availability as TLS 1.3 treats most 
malformed data as a fatal error.
--Mohit

[1] Extensible Authentication Protocol Vulnerabilities and Improvements : 
https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431=etd_projects
[2] An Initial Security Analysis of the IEEE 802.1X Standard : 
http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf

On 2/4/21 2:18 PM, John Mattsson wrote:
Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements 
Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into 
a small amount of ways where spoofed messages causes the TLS connection to 
fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically 
any small error is fatal in TLS. Focusing on alert messages does not seem 
correct. An attacker can e.g. at any time send a small record with length 2^15, 
which causes TLS to terminate the connection. I think the only thing that can 
be achieved without rewriting TLS is that availability attacks does not cause 
long-term damage, i.e. the nodes can retry the handshake.

- "An Initial Security Analysis of the IEEE 802.1X Standard"

  This paper discusses attacks on 801.11. The weaknesses described seems to 
come from 802.11 / EAP interactions.

The discussions around IETF 102 was that the uncertainty (NewSessionTicket or 
not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of 
the uncertainty. Bernard then pointed out that any message changing the state 
need to be authenticated to that it is not possible to spoof. I think that both 
the application layer commit message as well as close_notify fulfill these old 
requirements.


I think your analysis is correct.

1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 
protocol?

The -13 commitment message verifies that both sides are in possession of a 
derived key. But the server finished already does that. As you state, the -13 
commitment message is not an alternative success indication. I think it would 
be easy to make it an alternative success indication be mandating that the 
EAP-TLS server must only send it after verifying the client finished. I do not 
think defining a new exporter is needed.

The -14 close_notify is also not an alternative success indication and can not 
be made into one either.

If the requirement is that an alternative authenticated success indication is 
needed. Then I think:

- We need to have an extra roundtrip.
- close_notify does not work and cannot be made to work
- Application data commit message could work as an alternative success 
indication. TLS would have to be profiled so the alternative success is only 
send be EAP-TLS server after client finished processed successfully.

2. At what point should keys be pushed down to 

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi Martin,

Thanks for the quick response.

On 1/8/21 10:25 AM, Martin Thomson wrote:
> On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
>> Thanks for pointing this out. I think Ben also mentioned this in his
>> review. I am not sure if it is necessary to add the type-code to the
>> label when it is already part of the label string as 'EAP_TLS'. Other
>> TLS based EAP methods should ideally register labels of the form
>> EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the
>> EAP-TLS label) as is currently done in
>> https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.
> Sounds good to me.
>
>> I do agree with your point about the incorrect usage of the context.
>> Perhaps the ideal choice here would be Server-Id and Peer-Id (if client
>> certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2.
> Maybe, as I said, it depends.
>
>> However, I checked the wpa_supplicant implementation and currently these
>> values are not available. As far as I can tell, the Server-Id and
>> Peer-Id are not exported for any EAP method. So we'll need to think
>> what's the right thing to do: update implementation/use some other
>> sensible value/or leave the context empty (which is allowed in RFC 5705).
> This suggests that the values aren't critical to any decision making process 
> made by either peer and maybe you don't need to include them.  I would check 
> a little more thoroughly though.  One implementation not using them isn't 
> strong enough evidence that they aren't used at all.  If those identifiers 
> determine what certificate is selected, or anything like that, then it would 
> be good to ensure that peers agree on what they were.  That might mean making 
> them available in implementations that did not previously use them.  On the 
> other hand, if they are always going to be anonymous identifiers that have no 
> bearing on the TLS operation, don't worry about it and use the empty string.

These values are critical for making authorization decisions about 
network access. It is more a question of where these values are 
available, exported, and used for decision making in implementations. 
Thank you for nudging us in the right direction. :)

--Mohit

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi Ben,

On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M  wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation message, i.e. it should only be sent after
>>> receiving TLS Finished from the client? This would result in one extra
> I forget if it has been explicitly mentioned in the thread so far, but
> https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
> "Servers MAY send data after sending their first flight, but because the
> handshake is not yet complete, they have no assurance of either the peer's
> identity or its liveness (i.e., the ClientHello might have been replayed)."
> In particular, "no assurance of the peer's identity" means that the server
> is at this point sending to an unauthenticated client.  If the goal of
> EAP-TLS is to ascertain that there is in fact an authenticated client, it
> may be ill-advised to send indications of overall success to an
> unauthenticated client.  Part of what Martin alluded to with the situation
> being lousy overall is that there are basically two things that can
> cryptographically confirm that the client has authenticated: successful
> processing of the client Finished, and values derived from the resumption
> master secret.  In "normal" TLS usage the server will bail out if the
> client Finished doesn't validate, so continued receipt of application data,
> including application data bearing application-protocol responses to data
> the client sent in 1-RTT after client Finished, effectively implies that
> the server validated the client Finished, but the EAP-TLS usage is quite
> different from that.  There's not a cryptographic way to tell whether 0x00
> application data was generated before or after the client Finished was
> processed.
Yes, this was discussed. See email from Hannes 
(https://mailarchive.ietf.org/arch/msg/emu/Vf4Zor-xIDVZLQB-BE9mPvlDZMM/) 
where we did look at the text from RFC 8446 about the peer being 
unauthenticated. It was (at that time) accepted since the server was 
only committing to not sending more post-handshake messages (rather than 
indicating successful completion of handshake).
>
>>> round trip to both figure 1 and 3 in the current draft. So we would end
>>> up with the same number of messages as RFC 5216 for full authentication
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do
>>> worse than RFC 5216 (one extra round trip) in case resumption
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.2).
>>That sounds right.
> While counting arrows in the diagram like this is definitely useful, part
> of my concerns related to the need (in non-resumption flows) to convey the
> entire (enlarged) server Certificate chain in individual 1020-byte
> EAP-Requests.  My understanding was that the server had to send a single
> 1020-byte EAP-Request and wait for the corresponding EAP-Response before
> sending the next chunk of the certificate chain.  It was in that scenario
> that I expected a substantial difference between resumption and
> non-resumption.
>
>>> Maybe this is acceptable? The draft anyway notes that "Sending the
>>> Commitment Message in a separate EAP-Request adds an additional
>>> round-trip, but may be necessary in TLS implementations that only
>>> implement a subset of TLS 1.3.". In which case, I am not sure if the
>>> reasons against using close_notify apply anymore.
>>I won't offer opinions on TLS internals, as I'm out of my depth there.
>>
>>As an implementor, the priority is getting TLS alerts (expired cert, 
>> etc.) back from the EAP server to the EAP peer.  Those messages can then be 
>> used to debug deployment issues.
>>
>>The exact method of doing this is less important.  The "0x00" octet works 
>> now, so I'm happy with it.  But if TLS review decides that should change, 
>> that's fine, too.
> It's pretty much guaranteed that we can get the TLS alerts if we always
> wait for client Finished to be processed (whatever signal we end up
> choosing to send after that occurs).  Have we reached agreement on whether
> we should always wait for client Finished?

I hope so. I'll try to submit an update next week.

--Mohit

>
> -Ben
>
> ___
> 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] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi Martin,

Thanks for pointing this out. I think Ben also mentioned this in his 
review. I am not sure if it is necessary to add the type-code to the 
label when it is already part of the label string as 'EAP_TLS'. Other 
TLS based EAP methods should ideally register labels of the form 
EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the 
EAP-TLS label) as is currently done in 
https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.

I do agree with your point about the incorrect usage of the context. 
Perhaps the ideal choice here would be Server-Id and Peer-Id (if client 
certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. 
However, I checked the wpa_supplicant implementation and currently these 
values are not available. As far as I can tell, the Server-Id and 
Peer-Id are not exported for any EAP method. So we'll need to think 
what's the right thing to do: update implementation/use some other 
sensible value/or leave the context empty (which is allowed in RFC 5705).

--Mohit

On 1/8/21 12:41 AM, Martin Thomson wrote:
> Hi Joe,
>
> Thanks for doing this, I think that this is a distinct improvement (and I 
> will take your word for the difficulties involved with further splits).
>
> One point that I made poorly perhaps, and was dismissed, might be worth 
> restating:
>
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64)
>
> The inclusion of a type code as context is, I believe, a misuse of the field. 
>  As this is a fixed value, the value is being used for domain separation.  
> However, that is the function of the exporter label input.  The label exists 
> to establish that this is EAP-TLS and the key is (in this case) MSK.  If you 
> need different derivations for different type codes, I strongly suggest that 
> this be included in the label.
>
> The Context input exists to pull in variables from the context that endpoints 
> might need to agree on.  It is not for domain separation.  For example, if 
> you thought it necessary to authenticate the Identity values that client and 
> server exchange, you might add those to this field.  (As an aside, you might 
> want to consider that as their value could be used to determine what 
> parameters to feed into the TLS handshake.)
>
> If, however, you have an adjacent usage of EAP that wants its own MSK, then 
> that is domain separation.  The right thing to do would be to create new 
> labels for that usage.
>
> This might be a fine point in light of the fact that these all just get fed 
> into HKDF, but I think that it is important to respect the purpose for which 
> these inputs were designed.
>
> Cheers,
> Martin
>
> On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
>>
>> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok  wrote:
>>> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M  
>>> wrote:
>>>> Hi Alan,
>>>>
>>>> Cleaning up the email. The current draft says the exporter should be 
>>>> called once as:
>>>>
>>>>> Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
>>>>> Type-Code, 128)
>>>>>
>>>> and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
>>>> glance, it seems the exporter is called twice (once in eap_tls_get_emsk 
>>>> and once in eap_tls_getKey). Both the calls are with exactly the same 
>>>> context, context length, and labels. In getKey, the EMSK parts are cleared 
>>>> with
>>>>> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
>>>> while in get_emsk, they are read with
>>>>
>>>>
>>>>>   os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
>>>>>
>>>>> 
>>>>> EAP_EMSK_LEN);
>>>> Maybe we can live with this. But if exporter is called twice, we should 
>>>> use different labels as suggested by Martin?
>>>Yes.
>>>
>>>Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and 
>>> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>>>
>> [Joe] I created a pull request
>> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
>> proposed labels.  Is this change going to cause significant problems
>> for implementation?
>>   
>>>Alan DeKok.
>>>
>>> ___
>>> 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] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi Alan,

Cleaning up the email. The current draft says the exporter should be called 
once as:

   Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
   Type-Code, 128)

and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
glance, it seems the exporter is called twice (once in eap_tls_get_emsk and 
once in eap_tls_getKey). Both the calls are with exactly the same context, 
context length, and labels. In getKey, the EMSK parts are cleared with

os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);

while in get_emsk, they are read with

os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
  EAP_EMSK_LEN);

Maybe we can live with this. But if exporter is called twice, we should use 
different labels as suggested by Martin?

Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I was 
thrown off by Joe's comment "The mechanism for splitting the MSK into 
Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy cases 
(WEP, MPPE?)" and the fact that other EAP methods only export MSK. Other EAP 
methods leave it to the AAA architecture for splitting up the MSK. Why should 
EAP-TLS be different?

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi Joe,

On 1/5/21 8:44 AM, Joseph Salowey wrote:


On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Jan 3, 2021, at 10:44 PM, Martin Thomson 
mailto:m...@lowentropy.net>> wrote:
> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter output. 
>  This was something that old versions of TLS did, but TLS 1.3 did away with.  
> Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - 
> and should - do the same.  All it means is having more exporter labels.

  That's easy enough to change at this state.  The question is what are those 
labels?
  And, we're getting very close to needing an implementation soon.  RFC 8446 is 
over two years old.  Web services have started serious migration to TLS 1.3.  
But we still don't even have a standard for EAP.  I suggest that this is an 
issue.

  At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the 
major EAP peer / server implementations.  This code is alpha, and not in any 
major release.  But we need to decide fairly soon what we're doing, as testing 
and releases take time.

  The alternative is to dither around for another year or two, all the while 
relying on legacy TLS versions for 802.1X / WiFi authentication.  i.e. packets 
which are trivially monitored by anyone with a WiFi card.

> I appreciate that this uses exporters now rather than abusing the internal 
> PRF.  That's good.  The next step is to dispense with the intermediate values 
> (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS 
> exporter for each of the six values that the protocol requires.  I also note 
> that the 0x0D value is used multiple times, unnecessarily, both as a context 
> strong to the exporter and as a prefix to the session ID.

  If EAP-TLS was the only TLS-based EAP method, I would agree with you.  But 
it's not.  Historically, each TLS-based EAP method uses it's own key 
derivations, using method-specific strings.  This practice made implementations 
more difficult and error-prone.

[Joe] It may be worth having separate exporter tags for EMSK and MSK.  
(EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK).   I believe current 
applications define the use EAP key material based on the MSK or EMSK.   The 
mechanism for splitting the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is 
only used in specific legacy cases (WEP, MPPE?) and may still be the radius 
attributes used in some deployments, so I don't think we should alter that 
derivation.   I'm not sure where the IV is used, but I don't think splitting it 
up more will be helpful.

This sounds reasonable. I was initially hesitant to change because we have 
working implementations. But after a brief glance at the current hostap 
implementation: 
https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am 
convinced that using separate labels for MSK and EMSK is better. The current 
implementation seems incorrect.

About the IV: RFC 5247 (published after RFC 5216) says the following 
(https://tools.ietf.org/html/rfc5247#section-1.2):

As a result, its use has been deprecated and it is
  OPTIONAL for EAP methods to generate it.  However, when it is
  generated, it MUST be unpredictable.

Should we still export it in EAP-TLS with TLS 1.3?

And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in 
RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in 
hostap/freeradius implementations. It could be that they are still used by 
Microsoft but I am unsure?

--Mohit




  The use of 0x0D is to allow standard key derivations across TLS-based EAP 
methods.  The other methods replaced the 0x0D byte with their own EAP type 
value.  This practice greatly simplifies implementations.

  See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more 
information.

  Alan DeKok.

___
Emu mailing list
e...@ietf.org
https://www.ietf.org/mailman/listinfo/emu



___
Emu mailing list
e...@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi again,

The following issues are related but not exactly the same:
1. indication from the server that the handshake is complete and it is 
okay to tear down the tunnel
2. indication from the server that no more post-handshake messages 
(containing NewSessionTicket or something else) will be sent.

We can't rely on EAP-Success as an indication of either since that 
message is never delivered to EAP-TLS and it maybe lost or spoofed. 
Ben's discuss arises from 2 and not 1. More at the end of the email.

On 1/5/21 7:26 AM, Benjamin Kaduk wrote:
> Hi Martin,
>
> Thanks for chiming in here; your insight has been quite helpful already.
> (I am going to reply to the thread in reverse order so as to not duplicate
> what you've already said.)
>
> On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
>> Hi Alan,
>>
>> On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
>>> On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
 Your point about reliability is confusing.  I've read Section 4.2 of RFC 
 3748 and while it says "A peer MUST allow for this circumstance as 
 described in this note.", I see no explanation of how to concretely make 
 that allowance.  Are you saying that EAP methods don't really use 
 EAP-Success and condition their behaviour on other signals?
>>>EAP-Success by itself is *not* a reliable indication of Success.  See
>>> RFC 3748 Section 4.2:
>>>
>>> Success and Failure packets MUST NOT be sent by an EAP authenticator
>>> if the specification of the given method does not explicitly permit
>>> the method to finish at that point.
>> This is fine.  What you might be concerned about is the nature of the 
>> signals that the EAP authenticator is receiving from TLS.  What you had in 
>> the case of TLS 1.2 was the stack providing bytes to send (which were to go 
>> in EAP-Request) and then, after everything is done, a positive signal saying 
>> that the handshake was complete and satisfactory.  That latter signal is the 
>> important one.
> Yes.  Part of what had me so unhappy about this document is that the
> Commitment Message is discussed only as a "promise to not send more
> handshake messages", not "an indication that the handshake is complete and
> the TLS layer is happy".  (Furthermore, what Alan writes below about
> "cannot distinguish a "finished authentication" EAP-Success from a
> "spoofed" EAP-Success" really needs to make its way into the document.)
>
>> TLS 1.3 muddies things by allowing bytes to be sent *after* the 
>> complete+satisfactory signal from TLS.  That's what you are grappling with 
>> here.  What I'm suggesting is that you don't rely on looking at what bytes 
>> hit the wire, but wait until two conditions are complete:
>>
>> 1. The TLS stack says that it is content: the handshake is complete and it 
>> is OK with whatever the other side has provided.
>> 2. The TLS stack has no more bytes to send.
>>
>> The latter is likely where the confusion comes from, but if the stack 
>> doesn't produce bytes when you give it bytes, then you don't need to keep 
>> waiting.  For what you depend on, that's enough.
> I agree that this is probably good enough.  There may be some complications
> depending on how badly the availability of session resumption is desired (I
> know OpenSSL provides an API to let the application requst a new session
> ticket regardless of whether any were sent with the initial handshake -- I
> wrote it -- though I need to tweak it so that it will not always wait for
> application data to send before sending the ticket), but I believe this
> provides the key functionality.
>
>> The mistake with sending application data is that there is no obligation on 
>> the part of the TLS stack to order its sending of NewSessionTicket relative 
>> to the application data.  Nor is is possible for you to correctly 
>> distinguish TLS data that contains your Confirmation Message from a record 
>> that just contains a little bit of a session ticket.  But you don't need to 
>> worry about that.
>>
>> An example might help illustrate:
>>
>> 1. ... many steps occur
>> 2. Client sends EAP-Response ending in a TLS Finished.
>> 3. Server reads that message, processes it and determines that the handshake 
>> is complete and acceptable (e.g., checks the client certificate against its 
>> policy).
>> 4. As the server is happy, it writes the Confirmation Message to TLS.
>> 5. Server asks TLS stack for outstanding data to write; TLS stack provides a 
>> bunch of application_data records.
> (In particular, this is the TLSCiphext content type that is
> "application_data", and the inner content type could be handshake or
> application data.  The application doesn't have visibility into it.)
>
>> 6. Server writes TLS records into an EAP-Request and sends it.
>> 7. Client receives this and sends an empty EAP-Response.
>> 8. Server sends EAP-Success.
>>
>> This is, I assume what you intend here, with a little more detail around 
>> steps 3-5.  But what 

Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Top posting to explain the need for a reliable notification of protocol 
completion:

On 1/4/21 5:44 AM, Martin Thomson wrote:

 I have a much simpler one: the EAP layer has a signal that the protocol is 
complete: EAP-Success

Alan Dekok explained in a separate email thread why this is not the case 
(https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He 
wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  i.e. 
they are 4-bytes of data which can be spoofed rather trivially.".

There are two more quirks as to why EAP-Success cannot be used as an indication 
of protocol completion:

a) Section 2.2 of RFC 3748 says https://tools.ietf.org/html/rfc3748#section-2.2:

   EAP packets with Codes of Success or Failure do not include a Type
   field, and are not delivered to an EAP method.

What this means is that the EAP-Success is delivered to EAP (the framework) and 
not to EAP-TLS (the authentication method/protocol). Thus, EAP methods cannot 
rely on EAP-Success or EAP-Failure as an indication of anything since they 
never receive that message.

b) Section 3.1 (https://tools.ietf.org/html/rfc3748#section-3.1)  and 4.2 
(https://tools.ietf.org/html/rfc3748#section-4.2) of RFC 3748 says:

   Note that EAP Success and Failure packets are not retransmitted.
   Without a reliable lower layer, and with a non-negligible error rate,
   these packets can be lost


   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.

The knee-jerk reaction would be that EAP is bad and it should be fixed/updated. 
I have myself wondered if we can add some payload to the EAP-Success message. 
But EAP has been around for over a decade now and is used in many networks so 
the threshold for change is naturally high.

I also think that this should not be treated as an issue for EAP-TLS only. I 
can imagine other deployments which use TLS for making authorization decisions 
but do not use the TLS for sending message. So I am glad that Ben has brought 
this to the TLS working group for further discussion. Whether we use this 
1-byte of application data (as done in this draft) or some other mechanism 
(such as close_notify), we need a reliable way of telling that no further post 
handshake messages will be sent.

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

[TLS] Genart last call review of draft-ietf-tls-oldversions-deprecate-09

[Mohit Sethi via Datatracker]

Reviewer: Mohit Sethi
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-tls-oldversions-deprecate-09
Reviewer: Mohit Sethi
Review Date: 2020-11-25
IETF LC End Date: 2020-11-30
IESG Telechat date: Not scheduled for a telechat

Summary: This document deprecates older versions of TLS and DTLS. It also
updates many RFCs that normatively refer to the older TLS/DTLS versions.

Major issues: None

Minor issues: None

Nits/editorial comments: In section 1.1, typo in "waas defined to detect".

Most references to RFCs are of the form "[RFC7507]". Can we change "RFC 7457
[RFC7457]" to "[RFC7457]" for uniformity. Similarly, perhaps you could change
"RFC5246 [RFC5246]" and "RFC4346 [RFC4346]" to "[RFC5246]" and "[RFC4346]".

In section 2 "NIST for example have provided " should be "..has provided...".

In section 6 "this document is called out specifically to update text
implementing the deprecation  recommendations of this document." I was
initially confused with the repeated usage of "this". Perhaps it would help to
be more explicit.


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

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Mohit Sethi M]

+1 for a deterministic (minimal) encoding.

--Mohit

On 11/15/20 10:13 PM, Eric Rescorla wrote:
Trying to close out this discussion, it seems to me like there are three major 
options:

1. The current scheme
2. The current scheme with a deterministic minimal encoding (e.g., the two byte 
version is offset by 127)
3. The QUIC scheme

I don't think that the QUIC scheme with deterministic encoding makes sense, 
because the virtue of the QUIC scheme is commonality with something already 
defined. I'm hearing that people are not as excited about moving to QUIC as I 
had expected and to the best of my knowledge, there is no valid reason to 
encode to > 2^32-1 in TLS. I also don't think using encoding (1) but mandating 
minimal length makes sense, as it's just as easy to do a deterministic minimal 
encoding.

As Christian observes it *is* significantly more painful to do (2): the 
conventional way to encode vectors in TLS with minimal copying is:

- Mark your current place --> X
- Skip forward the length of the length field --> L
- Encode the value
- Encode (current position - (X + L)) at X

But this won't be possible in (2). As MT observes, if you think of this as a 
two-pass system, there is not as much of a problem here [though not necessarily 
no problem]. Also, if you use a separate buffer, there is no problem. As noted 
above by MT and others, cTLS expands the transcript and so having a 
deterministic compression scheme is perhaps not as important, given that 
decompression is deterministic, but it still seems nice to have.

Given the above, I think my preference would be (1) or (2), with, I think, a 
slight preference for (2).

-Ekr









On Tue, Oct 6, 2020 at 5:33 PM Nick Harper 
mailto:nhar...@google.com>> wrote:
I have no strong opinion on how this is formatted. I'd base my decision on what 
the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's keep it 
as is, otherwise let's change it to the QUIC format (or some other change to 
increase the max value). I do like that the existing scheme, compared to QUIC 
varints, is more efficient for values 64-127 and just as efficient for the rest.

On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
I don't have a strong opinion on whether to require a minimal encoding, but if 
we're not going to use QUIC's encoding as-is, then I would rather stick with 
the existing scheme, which has twice as large a range for the 1 byte encoding 
and is thus more compact for a range of common cases.

-Ekr


On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
mailto:martenseem...@gmail.com>> wrote:
In that case, why use QUIC's encoding at all? It would just put the burden on 
the receiver to check that the minimal encoding was used.
Would it instead make more sense to modify QUIC's encoding, such that the 
2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers 
from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?

On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
Can you just say “QUIC rules but use the minimum possible length”?
___
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] PR#28: Converting cTLS to QUIC-style varints

[Mohit Sethi M]

Hi Anders,

On 10/7/20 10:14 PM, Anders Rundgren wrote:
> On 2020-10-07 19:47, Mohit Sethi M wrote:
>> A strong +1 on the security issues of decode -> extract -> re-encode ->
>> verify signature flow. The lack of canonical encoding can also mean that
>> the resulting bytes can be different in different encoder/decoder
>> implementations.
>>
>> It would have been nice to have canonical JSON. Some implementations
>> support it with flags such as "JSON_PRESERVE_ORDER"
>> (https://jansson.readthedocs.io/en/2.8/apiref.html). Some specs try to
>> specify things like keys should be in alphabetical order but fail to
>> realize the complication with nested structures.
>
> Hi Mohit,
>
> Since a few months back there is an RFC (8785) which specifies a
> scheme for canonicalizing JSON, albeit limited to the JSON subset
> supported by ECMAScript and browsers.
>
> It can be tested in an on-line application where it is combined with
> JWS: https://mobilepki.org/jws-jcs/home

Cool ! Thanks for informing and thanks for doing the work!

--Mohit

>
> Anders
>
>>
>> CBOR has thankfully specified canonical representation (called as
>> deterministic encoding in 7049bis). Some CBOR libraries have added
>> support: https://github.com/agronholm/cbor2/issues/6.
>>
>> --Mohit
>>
>> On 10/7/20 7:30 AM, Watson Ladd wrote:
>>> On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema 
>>>  wrote:
>>>> On 10/6/2020 10:00 AM, Michael D'Errico wrote:
>>>>
>>>>> It matters in X.509 certificates because the basic
>>>>> encoding rules (BER) allow you to specify the same
>>>>> thing in different ways.  With DER, there is only
>>>>> one way to encode every element, so everybody will
>>>>> come up with the same string of bytes and hashes of
>>>>> those strings will be the same, signatures will
>>>>> verify, etc.
>>>>
>>>> Well, we have learned a few things since 1994. The DER rules are 
>>>> defined
>>>> to allow a "re-encoding" workflow:
>>>>
>>>> * Sender side: prepare the message, encode with DER, sign the result
>>>>
>>>> * Receiver side: receive the message, parser with generic ASN.1 
>>>> decoder,
>>>> process the message using the "parsed" representation, re-encode with
>>>> DER, check the signature.
>>>>
>>>> Experience showed that this workflow is very problematic, because the
>>>> parse/reencode process may introduce subtle changes and the signature
>>>> will fail.  One may argue that these changes are due to implementation
>>>> bugs, but fact it that this is a rich environment for growing bugs.
>>>> Based on experience, the receiver side is better done as:
>>>>
>>>> * Receiver side: receive the message, save it, parse and process, and
>>>> when it is time to verify the signature go back to the original 
>>>> message
>>>> and check the signature.
>>> Examining signed data ahead of verification, particularly to determine
>>> what should have signed it, is fraught with issues. In particular
>>> parser errors that would only be exploitable by trusted parties become
>>> exploitable by anyone. Furthermore, you should know the expected
>>> signer ahead of time. That this isn't possible in X509 due to
>>> inordinate flexibility is one of many pitfalls for implementors. This
>>> sort of issue periodically leads to authentication bypasses and other
>>> such fun.
>> A strong +1 to this.
>>>
>>> Sincerely,
>>> Watson Ladd
>>>
>>>
>>>
>>> -- 
>>> 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
>>
>
> ___
> 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] PR#28: Converting cTLS to QUIC-style varints

[Mohit Sethi M]

A strong +1 on the security issues of decode -> extract -> re-encode -> 
verify signature flow. The lack of canonical encoding can also mean that 
the resulting bytes can be different in different encoder/decoder 
implementations.

It would have been nice to have canonical JSON. Some implementations 
support it with flags such as "JSON_PRESERVE_ORDER" 
(https://jansson.readthedocs.io/en/2.8/apiref.html). Some specs try to 
specify things like keys should be in alphabetical order but fail to 
realize the complication with nested structures.

CBOR has thankfully specified canonical representation (called as 
deterministic encoding in 7049bis). Some CBOR libraries have added 
support: https://github.com/agronholm/cbor2/issues/6.

--Mohit

On 10/7/20 7:30 AM, Watson Ladd wrote:
> On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema  wrote:
>> On 10/6/2020 10:00 AM, Michael D'Errico wrote:
>>
>>> It matters in X.509 certificates because the basic
>>> encoding rules (BER) allow you to specify the same
>>> thing in different ways.  With DER, there is only
>>> one way to encode every element, so everybody will
>>> come up with the same string of bytes and hashes of
>>> those strings will be the same, signatures will
>>> verify, etc.
>>
>> Well, we have learned a few things since 1994. The DER rules are defined
>> to allow a "re-encoding" workflow:
>>
>> * Sender side: prepare the message, encode with DER, sign the result
>>
>> * Receiver side: receive the message, parser with generic ASN.1 decoder,
>> process the message using the "parsed" representation, re-encode with
>> DER, check the signature.
>>
>> Experience showed that this workflow is very problematic, because the
>> parse/reencode process may introduce subtle changes and the signature
>> will fail.  One may argue that these changes are due to implementation
>> bugs, but fact it that this is a rich environment for growing bugs.
>> Based on experience, the receiver side is better done as:
>>
>> * Receiver side: receive the message, save it, parse and process, and
>> when it is time to verify the signature go back to the original message
>> and check the signature.
> Examining signed data ahead of verification, particularly to determine
> what should have signed it, is fraught with issues. In particular
> parser errors that would only be exploitable by trusted parties become
> exploitable by anyone. Furthermore, you should know the expected
> signer ahead of time. That this isn't possible in X509 due to
> inordinate flexibility is one of many pitfalls for implementors. This
> sort of issue periodically leads to authentication bypasses and other
> such fun.
A strong +1 to this.
>
> Sincerely,
> Watson Ladd
>
>
>
> --
> 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] Review of draft-ietf-tls-external-psk-guidance-00

[Mohit Sethi M]

Hi Carrick,

Thank you for the review. I also added some comments in-line.

On 8/18/20 6:26 PM, 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
>> so, it might be worth mentioning that as a potential mitigation (as the
>> Selfie paper does).
> Indeed. That seems like a fine thing to mention.
>
>>> "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.)
> +1, I'm fine with dropping that bit.
>
>>> 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?
>
>>>   Applications should take precautions when using external PSKs to mitigate 
>>> these risks.
>> What sort of precautions should they take?
> Filed:https://github.com/tlswg/external-psk-design-team/issues/36
>
>>> 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.
>
>>> 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.
> Yep, I agree.
>
>>> 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"?
> I think the two phrases are basically equivalent, but if using "early data" 
> is more clear, let's go with that.
>
>>> 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?
> Good question. I'll let Mohit answer this, but my impression was that, unlike 
> the PSKs, each node has its own private key, which seemingly allows the 
> server to authenticate a specific client.
This use-case is described in the publication by Akhmetzyanova et al. 
https://eprint.iacr.org/2019/421.pdf. See section 4. In the scenario 
described by the authors, resource-constrained IoT devices are TLS 
clients. The PSK is used for authenticating the central server and 
client membership of the system. Only for rare device-specific 
operations requiring a higher-security level (such as device firmware 
update), the server can request resource-intensive client authentication 
with certificates after successfully establishing the connection with 
PSK. This deployment may seem somewhat artificial but it was necessary 
in the paper to explain the possible attack scenarios.
>>> 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.
>
>>> 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.)
> Great suggestion!
>
>>> PSK 

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

[Mohit Sethi M]

Top posting so that others on the list can chime in.

While discussing the privacy implications of external PSK identities, Jim 
Schaad in his email below recommends that we could describe techniques for 
importing external PSK identities (that may be typed in by the user). He 
suggests that we could consider using a construct based on one way hash 
functions so that the typed-in external PSK identity (presumably with not so 
good privacy properties) are never sent on the wire.

--Mohit

On 7/8/20 5:45 PM, Jim Schaad wrote:


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Wednesday, July 8, 2020 1:03 AM
To: Jim Schaad <mailto:i...@augustcellars.com>; Mohit 
Sethi M <mailto:mohit.m.se...@ericsson.com>; 
draft-ietf-tls-external-psk-guida...@ietf.org<mailto:draft-ietf-tls-external-psk-guida...@ietf.org>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00


Hi Jim,
On 7/6/20 7:06 PM, Jim Schaad wrote:





-Original Message-

From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>

Sent: Monday, July 6, 2020 3:10 AM

To: Jim Schaad <mailto:i...@augustcellars.com>; 
draft-ietf-tls-external-psk-

guida...@ietf.org<mailto:guida...@ietf.org>

Cc: tls@ietf.org<mailto:tls@ietf.org>

Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00



Hi Jim,



Thanks for the review. A clarifying question in-line.



On 7/2/20 12:02 AM, Jim Schaad wrote:

* In section 4 there is a statement that switching the roles of

servers which use PSKs will lead to weakening of security properties.

As this is a common scenario today in situations where you are doing

server-to-server communication, it would be useful to discuss just how

and how much this weakening occurs.  This was a complete surprise to

me and I don't know if it was supposed to be one.  Are there mitigations that

can be made?



* In section 7, The first sentence does not read, also It seems a bit

difficult to have a MUST in there when most of the items below are SHOULDs.

That seems to be a dissonance.



* Section 7.1.1 - The idea of having domain name suffixes on PSKs

seems to me to be a bad idea as this would seem to lower privacy levels.



I think you are referring to the PSK identity and not to the PSK.



As you know, the Network Access Identifiers (NAIs) used in EAP typically need

the domain name suffix for roaming, federation, etc.



This is true, it is also true that EAP is very strong on saying that if you 
have a choice, always send an anonymous version of the NAI if you have to do it 
in the clear.  This means that the domain can be used for correlation, but you 
do not have the full identity for that purpose.



I think that the EMU group is going to need to look at what level of privacy 
protection it is going to desire when using a PSK, but in that case there is no 
need for having  a domain suffix as that information is provided elsewhere.   
This might require keeping the TLS tunneling as an option to deal with passive 
attacks.

You are absolutely right about the preference for using anonymous identities. 
draft-ietf-emu-eap-tls13 currently says the following about resumption:

   It is RECOMMENDED to use a NAIs with the same realm in the resumption

   and the original full authentication.  This requirement allows EAP

   packets to be routable to the same destination as the original full

   authentication.  If this recommendation is not followed, resumption

   is likely to be impossible.  When NAI reuse can be done without

   privacy implications, it is RECOMMENDED to use the same anonymous NAI

   in the resumption, as was used in the original full authentication.

   E.g. the NAI @realm can safely be reused, while the NAI

   ZmxleG8=@realm cannot.
This document and the ensuing discussion pertains only to external PSKs and 
external PSK identities. I think I incorrectly used the word "issue" in my 
previous email as a more correct choice would have been "agree/establish" (i.e. 
the server and client agree on an external PSK and an external PSK identity). 
RFC 8446 doesn't place any restrictions on external PSK identities (other than 
the fact that they are at least 1 byte). If we are going to discourage the use 
of domain names in external PSK identities, would that be sufficient? What 
prevents me from using an external PSK identity of the type: 
my_strong_secret_psk_with_amazon_server?

I am not sure if we should recommend randomized external PSK identities of a 
certain minimum length. Perhaps it might be better to add a disclaimer about 
the privacy loss from carelessly chosen external PSK identities?

[JLS] There are going to be three different cases for external PSK identities: 
The identity if factory provisioned and carried in a file to the server,  the 
identity is factory provisioned and read by the user from the device, and it is 
hand chosen.  The first two cases

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

[Mohit Sethi M]

Hi Jim,

On 7/6/20 7:06 PM, Jim Schaad wrote:





-Original Message-
From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, July 6, 2020 3:10 AM
To: Jim Schaad <mailto:i...@augustcellars.com>; 
draft-ietf-tls-external-psk-
guida...@ietf.org<mailto:guida...@ietf.org>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00

Hi Jim,

Thanks for the review. A clarifying question in-line.

On 7/2/20 12:02 AM, Jim Schaad wrote:


* In section 4 there is a statement that switching the roles of
servers which use PSKs will lead to weakening of security properties.
As this is a common scenario today in situations where you are doing
server-to-server communication, it would be useful to discuss just how
and how much this weakening occurs.  This was a complete surprise to
me and I don't know if it was supposed to be one.  Are there mitigations that


can be made?



* In section 7, The first sentence does not read, also It seems a bit
difficult to have a MUST in there when most of the items below are SHOULDs.
That seems to be a dissonance.

* Section 7.1.1 - The idea of having domain name suffixes on PSKs
seems to me to be a bad idea as this would seem to lower privacy levels.



I think you are referring to the PSK identity and not to the PSK.

As you know, the Network Access Identifiers (NAIs) used in EAP typically need
the domain name suffix for roaming, federation, etc.



This is true, it is also true that EAP is very strong on saying that if you 
have a choice, always send an anonymous version of the NAI if you have to do it 
in the clear.  This means that the domain can be used for correlation, but you 
do not have the full identity for that purpose.

I think that the EMU group is going to need to look at what level of privacy 
protection it is going to desire when using a PSK, but in that case there is no 
need for having  a domain suffix as that information is provided elsewhere.   
This might require keeping the TLS tunneling as an option to deal with passive 
attacks.

You are absolutely right about the preference for using anonymous identities. 
draft-ietf-emu-eap-tls13 currently says the following about resumption:

   It is RECOMMENDED to use a NAIs with the same realm in the resumption
   and the original full authentication.  This requirement allows EAP
   packets to be routable to the same destination as the original full
   authentication.  If this recommendation is not followed, resumption
   is likely to be impossible.  When NAI reuse can be done without
   privacy implications, it is RECOMMENDED to use the same anonymous NAI
   in the resumption, as was used in the original full authentication.
   E.g. the NAI @realm can safely be reused, while the NAI
   ZmxleG8=@realm cannot.

This document and the ensuing discussion pertains only to external PSKs and 
external PSK identities. I think I incorrectly used the word "issue" in my 
previous email as a more correct choice would have been "agree/establish" (i.e. 
the server and client agree on an external PSK and an external PSK identity). 
RFC 8446 doesn't place any restrictions on external PSK identities (other than 
the fact that they are at least 1 byte). If we are going to discourage the use 
of domain names in external PSK identities, would that be sufficient? What 
prevents me from using an external PSK identity of the type: 
my_strong_secret_psk_with_amazon_server?

I am not sure if we should recommend randomized external PSK identities of a 
certain minimum length. Perhaps it might be better to add a disclaimer about 
the privacy loss from carelessly chosen external PSK identities?

--Mohit









I would like to understand the nature of the resulting privacy loss. Is it that 
a
passive attacker can now easily determine the server which issued the PSK
identity (and the server where it will eventually be used)?



While it I true that at least some of the privacy information has already been 
leaked in the PSK case, you know the address that is being talked to and the 
PSK identity that is passed.  If you look at using thigs like ESNI, doing this 
would appear to potentially give away the very information that is being hidden 
in that case.

The other problem with having domain based KIDs is that you could easily get 
some amount of correlation between the KIDs that are assigned in different 
domains.  You could end up with mohit.ietf and mohit.amazon and it would be 
quite reasonable to assume that both of those identities are going to be for 
the same entity, just in different domains.

Jim





--Mohit




* Section 7.1.2 - There seem to me to be three different places where
collisions will occur.  The importer function could get a collision,
there could be collisions with pre-TLS 1.2 external identifiers and
there could be collision with resumption keys.  There has been a huge
discussion about this in the EMU group and I don

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

[Mohit Sethi M]

Hi Jim,

Thanks for the review. A clarifying question in-line.

On 7/2/20 12:02 AM, Jim Schaad wrote:
> * In section 4 there is a statement that switching the roles of servers
> which use PSKs will lead to weakening of security properties.  As this is a
> common scenario today in situations where you are doing server-to-server
> communication, it would be useful to discuss just how and how much this
> weakening occurs.  This was a complete surprise to me and I don't know if it
> was supposed to be one.  Are there mitigations that can be made?
>
> * In section 7, The first sentence does not read, also It seems a bit
> difficult to have a MUST in there when most of the items below are SHOULDs.
> That seems to be a dissonance.
>
> * Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to
> me to be a bad idea as this would seem to lower privacy levels.

I think you are referring to the PSK identity and not to the PSK.

As you know, the Network Access Identifiers (NAIs) used in EAP typically 
need the domain name suffix for roaming, federation, etc.

I would like to understand the nature of the resulting privacy loss. Is 
it that a passive attacker can now easily determine the server which 
issued the PSK identity (and the server where it will eventually be used)?

--Mohit

>
> * Section 7.1.2 - There seem to me to be three different places where
> collisions will occur.  The importer function could get a collision, there
> could be collisions with pre-TLS 1.2 external identifiers and there could be
> collision with resumption keys.  There has been a huge discussion about this
> in the EMU group and I don't find the text here to be sensible in term of
> whether this is or is not a problem.
>
> * Section 7.1.2 - One of the things that I kept meaning to get to and just
> haven't done so yet, is dealing with the question of can the TLS Key binders
> in the handshake to distinguish between multiple keys that happen to have
> the same identity.  Perhaps you should look to see if this does work and if
> it is safe.
>
> Jim
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance

[Mohit Sethi M]

As a member of the design team (and a co-author), I naturally support 
the adoption of this document.

I also take this opportunity to thank Chris Wood for shepherding the 
design team and getting the document ready.

--Mohit

On 6/5/20 6:05 PM, Sean Turner wrote:
> Just a reminder that this call ends today.
>
> So far we’ve only seen one response. I think I can safely say assume that the 
> 12 people on the DT agree, but let me know I got that wrong.
>
> spt
>
>> On May 21, 2020, at 22:12, Sean Turner  wrote:
>>
>> This is a WG document adoption call for draft-dt-tls-external-psk-guidance 
>> (aka Guidance for External PSK Usage in TLS). This effort was kicked off 
>> @IETF106 by Ben Kaduk and supported by others in the audience. There was 
>> also some nominal amount of support for adopting the draft at the last 
>> virtual interim though no formal adoption call was issued at the interim.
>>
>> If you support adopting this draft as a WG Document, then please send email 
>> indicating your support to the list. If you have any comments or 
>> reservations send them to the list too.
>>
>> This adoption call completes at 2359 UTC 5 June 2020.
>>
>> Cheers,
>> spt (for 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

Re: [TLS] External PSK design team

[Mohit Sethi M]

Just to clarify myself further, I would not want us to change the TLS 
1.3 protocol. I would rather have this design team produce an 
informational document that discusses considerations when using external 
PSKs in different settings, as well as, privacy of PSK identities and 
possible mitigations.

--Mohit

On 1/21/20 1:26 PM, Mohit Sethi M wrote:
> Thanks for clarifying. I would still like that this design team to have
> a narrow scope. As Sean said in his initial email:
>
>> forming a design team to focus on external PSK management and usage for TLS
> --Mohit
>
> On 1/21/20 12:40 PM, Björn Haase wrote:
>>> Mohit Sethi M  wrote:
>>> I would let CFRG deal with the PAKE selection process:
>>> and not have this design team spend time and energy on designing PAKEs.
>> That was not what I was suggesting. Instead, I was suggesting to 
>> *incorporate* the results of the selection process into TLS, such that there 
>> is an option allowing for security also in case of a "Low-Entropy"-PSK. 
>> Possibly, if the PAKE substep actually happens to be no more complex than 
>> Diffie-Hellmann, it might be worth to consider the PAKE as the default 
>> mechanism for any PSK-based key establishment that authenticates an 
>> ephemeral new session key with a PSK mechanism.?
>>
>> Yours,
>>
>> Björn.
>>
>>
>> Mit freundlichen Grüßen I Best Regards
>>
>> Dr. Björn Haase
>>
>>
>> Senior Expert Electronics | TGREH Electronics Hardware
>> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | 
>> Germany
>> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
>> bjoern.ha...@endress.com |  www.conducta.endress.com
>>
>>
>>
>> Endress+Hauser Conducta GmbH+Co.KG
>> Amtsgericht Stuttgart HRA 201908
>> Sitz der Gesellschaft: Gerlingen
>> Persönlich haftende Gesellschafterin:
>> Endress+Hauser Conducta Verwaltungsgesellschaft mbH
>> Sitz der Gesellschaft: Gerlingen
>> Amtsgericht Stuttgart HRA 201929
>> Geschäftsführer: Dr. Manfred Jagiella
>>
>>
>> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, 
>> wenn wir personenbezogene Daten von Ihnen erheben.
>> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
>> (https://www.endress.com/de/cookies-endress+hauser-website) nach.
>>
>>
>>
>> Disclaimer:
>>
>> The information transmitted is intended only for the person or entity to 
>> which it is addressed and may contain confidential, proprietary, and/or 
>> privileged material. Any review, retransmission, dissemination or other use 
>> of, or taking of any action in reliance upon, this information by persons or 
>> entities other than the intended recipient is prohibited. If you receive 
>> this in error, please contact the sender and delete the material from any 
>> computer. This e-mail does not constitute a contract offer, a contract 
>> amendment, or an acceptance of a contract offer unless explicitly and 
>> conspicuously designated or stated as such.
>>
>> ___
>> 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] External PSK design team

[Mohit Sethi M]

Thanks for clarifying. I would still like that this design team to have 
a narrow scope. As Sean said in his initial email:

> forming a design team to focus on external PSK management and usage for TLS

--Mohit

On 1/21/20 12:40 PM, Björn Haase wrote:
>> Mohit Sethi M  wrote:
>> I would let CFRG deal with the PAKE selection process:
>> and not have this design team spend time and energy on designing PAKEs.
> That was not what I was suggesting. Instead, I was suggesting to 
> *incorporate* the results of the selection process into TLS, such that there 
> is an option allowing for security also in case of a "Low-Entropy"-PSK. 
> Possibly, if the PAKE substep actually happens to be no more complex than 
> Diffie-Hellmann, it might be worth to consider the PAKE as the default 
> mechanism for any PSK-based key establishment that authenticates an ephemeral 
> new session key with a PSK mechanism.?
>
> Yours,
>
> Björn.
>
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
>
> Senior Expert Electronics | TGREH Electronics Hardware
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | 
> Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> bjoern.ha...@endress.com |  www.conducta.endress.com
>
>
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
>   
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, 
> wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
> (https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>   
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential, proprietary, and/or 
> privileged material. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you receive this 
> in error, please contact the sender and delete the material from any 
> computer. This e-mail does not constitute a contract offer, a contract 
> amendment, or an acceptance of a contract offer unless explicitly and 
> conspicuously designated or stated as such.
>   
> ___
> 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] External PSK design team

[Mohit Sethi M]

I would let CFRG deal with the PAKE selection process: 
https://mailarchive.ietf.org/arch/msg/cfrg/-a1sW3jK_5avmb98zmFbCNLmpAs 
and not have this design team spend time and energy on designing PAKEs.

--Mohit

On 1/21/20 11:52 AM, Björn Haase wrote:
> Hello to all,
>
> I am also willing to contribute. My concern is that I observe that in some 
> industrial control applications, PSK mechanisms (that actually require 
> high-entropy keys) are (mis)-used in conjunction with TLS, where the PSK is 
> actually of insufficient entropy (maybe derived only from a 4 digit PIN).
>
> In order to fix this issue, I'd really appreciate to have an PSK-style TLS 
> operation using a balanced PAKE (note that this could be implemented with 
> virtually no computational overhead in comparison to conventional ECDH 
> session key generation).
>
> Yours,
>
> Björn.
>
>
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
>
> Senior Expert Electronics | TGREH Electronics Hardware
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | 
> Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> bjoern.ha...@endress.com |  www.conducta.endress.com
>
>
>
>
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
>   
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, 
> wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
> (https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>   
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential, proprietary, and/or 
> privileged material. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you receive this 
> in error, please contact the sender and delete the material from any 
> computer. This e-mail does not constitute a contract offer, a contract 
> amendment, or an acceptance of a contract offer unless explicitly and 
> conspicuously designated or stated as such.
>   
>
>
> -Ursprüngliche Nachricht-
> Von: TLS  Im Auftrag von Mohit Sethi M
> Gesendet: Dienstag, 21. Januar 2020 10:45
> An: Colm MacCárthaigh ; Sean Turner 
> Cc: TLS List 
> Betreff: Re: [TLS] External PSK design team
>
> I am certainly interested and willing to contribute. We need some
> consensus on whether PSKs can be shared with more than 2 parties,
> whether the parties can switch roles, etc.
>
> EMU is going to work on EAP-TLS-PSK and the question of
> privacy/identities will pop-up there too.
>
> --Mohit
>
> On 1/21/20 7:33 AM, Colm MacCárthaigh wrote:
>> Interested, as it happens - this is something I've been working on at Amazon.
>>
>> On Mon, Jan 20, 2020 at 8:01 PM Sean Turner  wrote:
>>> At IETF 106, we discussed forming a design team to focus on external PSK 
>>> management and usage for TLS. The goal of this team would be to produce a 
>>> document that discusses considerations for using external PSKs, privacy 
>>> concerns (and possible mitigations) for stable identities, and more 
>>> developed mitigations for deployment problems such as Selfie. If you have 
>>> an interest in participating on this design team, please reply to this 
>>> message and state so by 2359 UTC 31 January 2020.
>>>
>>> Cheers,
>>>
>>> Joe and Sean
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7Cbjoern.haase%40endress.com%7C5af7f9dcd2f746b6638a08d79e56a7dc%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637151967330246544sdata=xtt%2F1mxS0XbrTQ8mExdzUP%2F%2BHSJKrXANsVqsX%2F4sUZA%3Dreserved=0
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7Cbjoern.haase%40endress.com%7C5af7f9dcd2f746b6638a08d79e56a7dc%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637151967330246544sdata=xtt%2F1mxS0XbrTQ8mExdzUP%2F%2BHSJKrXANsVqsX%2F4sUZA%3Dreserved=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] External PSK design team

[Mohit Sethi M]

I am certainly interested and willing to contribute. We need some 
consensus on whether PSKs can be shared with more than 2 parties, 
whether the parties can switch roles, etc.

EMU is going to work on EAP-TLS-PSK and the question of 
privacy/identities will pop-up there too.

--Mohit

On 1/21/20 7:33 AM, Colm MacCárthaigh wrote:
> Interested, as it happens - this is something I've been working on at Amazon.
>
> On Mon, Jan 20, 2020 at 8:01 PM Sean Turner  wrote:
>> At IETF 106, we discussed forming a design team to focus on external PSK 
>> management and usage for TLS. The goal of this team would be to produce a 
>> document that discusses considerations for using external PSKs, privacy 
>> concerns (and possible mitigations) for stable identities, and more 
>> developed mitigations for deployment problems such as Selfie. If you have an 
>> interest in participating on this design team, please reply to this message 
>> and state so by 2359 UTC 31 January 2020.
>>
>> Cheers,
>>
>> 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

Re: [TLS] Imported Keys/PR #22

[Mohit Sethi M]

I believe that my pull request was indeed covering the different cases you talk 
about. See in-line pieces of text from my pull request:

On 11/21/19 10:48 AM, Eric Rescorla wrote:
To recap what I was saying at the microphone earlier today about
selfie/reroute issues, there are actually three separate issues.

- A reflection attack where an outside attacker makes the client also
  act as a server.

- A reroute attack where an outside attacker makes the client talk to
  another server with the same PSK as the intended server.

- An attack where an inside attacker impersonates another attacker
  who also has the PSK.

The reflection attack is a special case of the reroute attack.  The
general solution to the reroute attack is to carry the identities of
the communicating endpoints in the handshake [0]; AFAIK it's not
necessary to have separate keys, though the current text actually
generates distinct keys for each pair as well.  It's not a problem to
have distinct keys, but it's important to know what piece does what.

Selfie attack {{Selfie}} is a special case of the rerouting attack against a 
group member that can act both as TLS server and client. In the selfie attack, 
a malicious non-member reroutes a connection from the client to the server on 
the same endpoint.

Rerouting and selfie attacks can be detected by binding the TLS handshake to 
globally unique node identifiers using the following context string:
struct {
   opaque client_id<0..2^16-1>;
   opaque server_id<0..2^16-1>;
  } Context;


However, that doesn't generally solve the third class of attack if the
inside attacker is configured with the input key rather than the
fanned out pairwise keys.


When the PSK is a group key: To prevent malicious rerouting in groups, each 
endpoint needs to know the identifier of the other endpoint with which they 
want to connect and compare it with the other endpoint’s identifier in context. 
Of course, this only prevents attacks by non-members; the endpoints that share 
the group key can always impersonate each other.

The last part was explicitly referring to the case that you can't do much about 
insider attacks in group PSK scenarios.

-Ekr

[0] As John Mattson has pointed out, you can fix just the reflection
attack by comparing the random values you have outstanding in each
direction.


I find the current text in draft-ietf-tls-external-psk-importer inadequate 
(although I understand that I am in the rough). For example, it doesn't 
explicitly say that client_mac should never be the same as the server_mac. If 
the WG wants to address this in a separate document, then so be it. I am happy 
to help.

--Mohit






___
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] Selfie attack

[Mohit Sethi M]

Hi John,

I hope you also check the text for addressing Selfie attacks in the pull 
request I created Chris. Some more comments below.

--Mohit

On 10/11/19 10:38 AM, John Mattsson wrote:

Thanks Mohit,



Re-reading the Selfie paper I see that the authors define Client Alice and 
Server Alice as different members of the group. That makes things clearer. I 
think there are three cases:



  1.  Use cases where only Client Alice and Server Bob shares the PSK are not 
vulnerable to the Selfie attack.



  1.  Cases where Alice, Bob, and Caesar share an external PSK seem like 
misconfiguration, I assume TLS 1.3 just forgot to explicitly forbid them.



  1.  The interesting use case if where Client Alice, Server Alice, Client Bob, 
and Server Bob shares a PSK. That is a very valid use case and one that is 
currently deployed in several systems.



To do as the Selfie authors suggest “A PSK MUST NOT be shared between more than 
one client and one server” seems way too drastic as is forbids 3 above. For 3 I 
think the Selfie attack can be very easily mitigated by forcing clients to 
check incoming ServerHello.random.



I think something like the following updates for RFC 8446 would be enough:



“A PSK MUST NOT be shared between more than two endpoints”

What is a bug for you maybe is a feature for someone else. I wish we could put 
the requirement you suggest but there are several people who use PSKs that are 
shared by more than two nodes.




“An endpoint receiving a ClientHello with PSK authentication MUST check that 
the ClientHello.random is not equal to a ClientHello.random that the endpoint 
previously sent and has not received a ServerHello.”

This is one possible solution. In effect you are using the CleintHello.random 
and ServerHello.random as endpoint identifiers. However, it seems cleaner to 
not re-use random nonces from the cryptographic protocols as identifiers.



Cheers,

John

From: TLS <mailto:tls-boun...@ietf.org> on behalf of 
Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
Date: Tuesday, 8 October 2019 at 21:08
To: Christian Huitema <mailto:huit...@huitema.net>, 
Christopher Wood <mailto:c...@heapingbits.net>, Mohit 
Sethi M <mailto:mohit.m.se...@ericsson.com>, 
"TLS@ietf.org"<mailto:TLS@ietf.org> <mailto:tls@ietf.org>
Subject: Re: [TLS] Selfie attack


Hi Christian,

It was my poor attempt at explaining the attack. The attack can happen as long 
as a node sends outbound connections (as a TLS client) and accepts inbound 
connections (as a TLS server) with the same external PSK and identity. This is 
likely to happen in some form of group communication but not necessarily.

In such a scenario, a malicious node Eve can fool Alice to open a connection to 
herself (hence the name Selfie).

Admittedly, UKS/misbinding/selfie are somewhat hard to comprehend sometimes (at 
least for me).

--Mohit
On 10/8/19 9:51 PM, Christian Huitema wrote:

On 10/8/2019 9:46 AM, Christopher Wood wrote:

On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:



Hi Chris,



For the benefit of the list, let me summarize that the selfie attack is

only relevant where multiple parties share the same PSK and use the

same PSK for outgoing and incoming connections. These situations are

rather rare, but I accept that TLS is widely used (and sometimes

misused) in many places.



I may be getting old but the way Mohit writes it, it seems that the attack 
happens when the security of a group relies on a secret shared by all members 
of the group, and can then be compromised when one of the group members 
misbehaves. How is that a new threat? If groups are defined by a shared secret, 
then corruption of a group member reveals that shared secret to the attacker 
and open the path for all kinds of exploitation. In what sense is the "selfie" 
attack different from that generic threat?

-- Christian Huitema



___

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

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

Re: [TLS] Selfie attack

[Mohit Sethi M]

Hi Chris and Christian,

I would disagree. The important thing to note is that the selfie attack 
is not a traditional insider attack where someone with the PSK 
misbehaves. If you look at the paper (https://eprint.iacr.org/2019/347), 
you will notice that Eve can fool Alice into opening a connection with 
herself without knowing the PSK that Alice shares with Bob. If Eve knew 
the PSK, then certainly it could pretend to be any one of the parties in 
the group that shares the PSK.

--Mohit

On 10/9/19 2:48 AM, Christopher Wood wrote:
> On Tue, Oct 8, 2019, at 11:51 AM, Christian Huitema wrote:
>>   
>> On 10/8/2019 9:46 AM, Christopher Wood wrote:
>>
>>> On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>>>>   
>> Hi Chris,
>>
>> For the benefit of the list, let me summarize that the selfie attack is
>> only relevant where multiple parties share the same PSK and use the
>> same PSK for outgoing and incoming connections. These situations are
>> rather rare, but I accept that TLS is widely used (and sometimes
>> misused) in many places.
>>
>>
>> I may be getting old but the way Mohit writes it, it seems that the
>> attack happens when the security of a group relies on a secret shared
>> by all members of the group, and can then be compromised when one of
>> the group members misbehaves. How is that a new threat? If groups are
>> defined by a shared secret, then corruption of a group member reveals
>> that shared secret to the attacker and open the path for all kinds of
>> exploitation. In what sense is the "selfie" attack different from that
>> generic threat?
> In my opinion, it's not.
>
> Best,
> Chris
>
> ___
> 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] Selfie attack

[Mohit Sethi M]

Hi,

I created a pull request for the draft to improve the section on 
addressing selfie attacks. For the benefit of the list, here is the 
proposed text:

> The TLS external PSK authentication makes the implicit assumption that 
> each PSK is known only to one client and one server, which do not 
> switch roles with the same PSK.
>
> If multiple clients or multiple servers share a PSK, TLS only 
> authenticates the entire group. Not only can a compromised group 
> member impersonate another group member, but a malicious non-member 
> can reroute handshakes between honest group members to connect them in 
> unintended ways. This rerouting is a type of identity misbinding 
> attack [Krawczyk][Sethi].
>
> Selfie attack [Selfie] is a special case of the rerouting attack 
> against a group member that can act both as TLS server and client. In 
> the selfie attack, a malicious non-member reroutes a connection from 
> the client to the server on the same endpoint.
>
> Rerouting and selfie attacks can be detected by binding the TLS 
> handshake to globally unique node identifiers using the following 
> context string:
>
> struct {
>    opaque client_id<0..2^16-1>;
>    opaque server_id<0..2^16-1>;
>  } Context;
>
> When the PSK is shared by only two endpoints, it is not necessary to 
> know the identifier(s) of the other endpoint. Instead, it is 
> sufficient to check that the identifier of the other endpoint in 
> context is not equal to any of one’s own identifiers. To simplify 
> implementation of this check, it is RECOMMENDED that each endpoint 
> selects one globally unique identifier and uses it in all PSK 
> handshakes. The unique identifier can, for example, be one of its MAC 
> addresses or a 32-byte random number.
>
> When the PSK is a group key, the comparison with one’s own identifiers 
> will only prevent selfie attacks but not malicious rerouting of the 
> connection to another group member. To prevent malicious rerouting in 
> groups, each endpoint needs to know the identifier of the other 
> endpoint with which they want to connect and compare it with the other 
> endpoint’s identifier in context. Of course, this only prevents 
> attacks by non-members; the endpoints that share the group key can 
> always impersonate each other.

--Mohit

On 10/8/19 7:46 PM, Christopher Wood wrote:
> On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>>   
>> Hi Chris,
>>
>> For the benefit of the list, let me summarize that the selfie attack is
>> only relevant where multiple parties share the same PSK and use the
>> same PSK for outgoing and incoming connections. These situations are
>> rather rare, but I accept that TLS is widely used (and sometimes
>> misused) in many places.
>>
>> The Selfie attack only happens when an entity with the PSK acts
>> maliciously. So I think the fact that you write in the draft: "each
>> node must be trusted not to impersonate another node's role" does not
>> take into account that there must be a malicious node for the selfie
>> attack to happen in the first place.
>>
>> Drucker and Gueron's paper recommends that "every participating party
>> gets (during the setup of the network) a unique identity" and "the
>> client and the server must verify the validity of the claimed
>> identities.". The reality however is that in most group PSK scenarios,
>> the nodes don't have any strong identities that can be verified.
>>
>> What you should instead (or additionally) say in the text is that a
>> node should check that the client_mac and server_mac (or any other
>> identities used) *are never the same*.
> This seems implicit in the text as written. Could I ask you to submit a PR 
> against [1] to clarify?
>
> Thanks,
> Chris
>
> [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer
>
>> Without this check, the selfie
>> attack would still be possible. And at least this does not require
>> strong identity verification for preventing selfie attacks.
>>
>> --Mohit
>>
>> On 10/5/19 2:41 PM, Christopher Wood wrote:
>>> Hi Feng,
>> For what it's worth, the latest version of the PSK importers draft
>> includes a "context" field into which identity information can be fed:
>>
>> 
>> https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#appendix-B
>>
>> Best,
>> Chris
>>
>> On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote:
>>>> Hi John,
>> Reflection attacks are indeed older, but the selfie attack is a bit
>> different. It's actually a variant of the unknown key share atta

Re: [TLS] Selfie attack

[Mohit Sethi M]

Hi Christian,

It was my poor attempt at explaining the attack. The attack can happen as long 
as a node sends outbound connections (as a TLS client) and accepts inbound 
connections (as a TLS server) with the same external PSK and identity. This is 
likely to happen in some form of group communication but not necessarily.

In such a scenario, a malicious node Eve can fool Alice to open a connection to 
herself (hence the name Selfie).

Admittedly, UKS/misbinding/selfie are somewhat hard to comprehend sometimes (at 
least for me).

--Mohit

On 10/8/19 9:51 PM, Christian Huitema wrote:

On 10/8/2019 9:46 AM, Christopher Wood wrote:

On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:



Hi Chris,

For the benefit of the list, let me summarize that the selfie attack is
only relevant where multiple parties share the same PSK and use the
same PSK for outgoing and incoming connections. These situations are
rather rare, but I accept that TLS is widely used (and sometimes
misused) in many places.


I may be getting old but the way Mohit writes it, it seems that the attack 
happens when the security of a group relies on a secret shared by all members 
of the group, and can then be compromised when one of the group members 
misbehaves. How is that a new threat? If groups are defined by a shared secret, 
then corruption of a group member reveals that shared secret to the attacker 
and open the path for all kinds of exploitation. In what sense is the "selfie" 
attack different from that generic threat?

-- Christian Huitema



___
TLS mailing list
TLS@ietf.org<mailto: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] Selfie attack

[Mohit Sethi M]

Hi John,

On 10/8/19 1:14 PM, John Mattsson wrote:
Hi Mohit, that are good points.

> The reality however is that in most group PSK scenarios, the nodes don't have 
> any strong identities that can be verified.
I assume blocking all identities that are not the nodes own identity would 
mitigate the attacks, but lead to availability problems as two nodes with the 
same chosen identity cannot talk to each other.
Well this is getting off-topic, but if identities are generated randomly and 
are long enough, collisions shouldn't be a problem. Some MAC address 
randomization implementations simply generate a new address if they detect a 
collision. But we will soon start discussing the problem of address squatting 
and want Cryptographically Generated Address (CGAs). So perhaps we can leave 
the identity collision and squatting problem to the actual deployment.

>What you should instead (or additionally) say in the text is that a node 
>should check that the client_mac and server_mac (or any >other identities 
>used) are never the same.

I think checking ClientHello.random is enough. Below is what we wrote in

On this, Drucker and Gueron's paper mentions that a possible solution is: 
"Every party (client or server) caches all the nonces that it generated, and 
rejects a connection from other parties if they use a cached nonce." and that 
it "involves the overhead of maintaining a cache and the overhead of sharing 
the cache between several processes on the same node.". The paper also 
describes a group scenario where nodes can inadvertently leak cache and memory 
information if something like this is implemented. So I think that ensuring 
non-equal client and server identities is easier and safer since this check can 
be performed before the TLS handshake begins (i.e. when the external PSK is 
transformed to ipskx).

--Mohit
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-14

  “If two nodes unintentionally initiate two simultaneous EDHOC message
   exchanges with each other even if they only want to complete a single
   EDHOC message exchange, they MAY terminate the exchange with the
   lexicographically smallest G_X.  If the two G_X values are equal, the
   received message_1 MUST be discarded to mitigate reflection attacks.
   Note that in the case of two simultaneous EDHOC exchanges where the
   nodes only complete one and where the nodes have different preferred
   cipher suites, an attacker can affect which of the two nodes'
   preferred cipher suites will be used by blocking the other exchange.”

John

From: TLS <mailto:tls-boun...@ietf.org> on behalf of 
Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
Date: Tuesday, 8 October 2019 at 11:57
To: Christopher Wood <mailto:c...@heapingbits.net>, 
"TLS@ietf.org"<mailto:TLS@ietf.org> <mailto:tls@ietf.org>
Subject: Re: [TLS] Selfie attack


Hi Chris,

For the benefit of the list, let me summarize that the selfie attack is only 
relevant where multiple parties share the same PSK and use the same PSK for 
outgoing and incoming connections. These situations are rather rare, but I 
accept that TLS is widely used (and sometimes misused) in many places.

The Selfie attack only happens when an entity with the PSK acts maliciously. So 
I think the fact that you write in the draft: "each node must be trusted not to 
impersonate another node's role" does not take into account that there must be 
a malicious node for the selfie attack to happen in the first place.

Drucker and Gueron's paper recommends that "every participating party gets 
(during the setup of the network) a unique identity" and "the client and the 
server must verify the validity of the claimed identities.". The reality 
however is that in most group PSK scenarios, the nodes don't have any strong 
identities that can be verified.

What you should instead (or additionally) say in the text is that a node should 
check that the client_mac and server_mac (or any other identities used) are 
never the same. Without this check, the selfie attack would still be possible. 
And at least this does not require strong identity verification for preventing 
selfie attacks.

--Mohit
On 10/5/19 2:41 PM, Christopher Wood wrote:

Hi Feng,



For what it's worth, the latest version of the PSK importers draft includes a 
"context" field into which identity information can be fed:



   
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#appendix-B



Best,

Chris



On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote:

Hi John,



Reflection attacks are indeed older, but the selfie attack is a bit

different. It's actually a variant of the unknown key share attack. A

typical example of the UKS attack is the one reported on MQV by Kaliski

in 2001 (see "An unknown key-share attack on the MQV key agreement

protocol" in ACM TISSEC 2001). In that example

Re: [TLS] Selfie attack

[Mohit Sethi M]

Hi Chris,

For the benefit of the list, let me summarize that the selfie attack is only 
relevant where multiple parties share the same PSK and use the same PSK for 
outgoing and incoming connections. These situations are rather rare, but I 
accept that TLS is widely used (and sometimes misused) in many places.

The Selfie attack only happens when an entity with the PSK acts maliciously. So 
I think the fact that you write in the draft: "each node must be trusted not to 
impersonate another node's role" does not take into account that there must be 
a malicious node for the selfie attack to happen in the first place.

Drucker and Gueron's paper recommends that "every participating party gets 
(during the setup of the network) a unique identity" and "the client and the 
server must verify the validity of the claimed identities.". The reality 
however is that in most group PSK scenarios, the nodes don't have any strong 
identities that can be verified.

What you should instead (or additionally) say in the text is that a node should 
check that the client_mac and server_mac (or any other identities used) are 
never the same. Without this check, the selfie attack would still be possible. 
And at least this does not require strong identity verification for preventing 
selfie attacks.

--Mohit

On 10/5/19 2:41 PM, Christopher Wood wrote:

Hi Feng,

For what it's worth, the latest version of the PSK importers draft includes a 
"context" field into which identity information can be fed:

   
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#appendix-B

Best,
Chris

On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote:


Hi John,

Reflection attacks are indeed older, but the selfie attack is a bit
different. It's actually a variant of the unknown key share attack. A
typical example of the UKS attack is the one reported on MQV by Kaliski
in 2001 (see "An unknown key-share attack on the MQV key agreement
protocol" in ACM TISSEC 2001). In that example, the adversary plays
message between two users to cause confusion in the identity, but in
Selfie, the adversary plays message with only one user and uses another
instance of the user to cause confusion in the identity. When we
reported this variant of UKS in [3], we were not aware of anything like
that in the literature.

Cheers,
Feng

On 24/09/2019, 16:17, "John Mattsson" 
<mailto:john.matts...@ericsson.com> wrote:

Hi,

I think these reflection attacks are much older than this. I quick
search for reflection attack security protocol gives a lot of old
results, The description of reflection attack in the following lecture
material from 2009 looks just like the "selfie attack" on TLS 1.3
http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf

With multiple sections there are other things that change as well.
If two nodes unintentionally initiate simultaneous ClientHello to each
other, even if they only want a single secure connection (I have seen
live systems where this happens in practice), an attacker can select
which ClientHello to block (e.g. the one with the strongest
cryptographic parameters). The following security property would then
no longer hold :

  "Downgrade protection:  The cryptographic parameters should be the
  same on both sides and should be the same as if the peers had been
  communicating in the absence of an attack"

(I have not looked at what the definitions in [BBFGKZ16] say).

Cheers,
John

-Original Message-
From: TLS <mailto:tls-boun...@ietf.org> on behalf of 
"Hao, Feng"
<mailto:feng@warwick.ac.uk>
Date: Tuesday, 24 September 2019 at 16:09
To: Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>,
"Owen Friel (ofriel)" <mailto:ofr...@cisco.com>, Jonathan 
Hoyland
<mailto:jonathan.hoyl...@gmail.com>
Cc: "TLS@ietf.org"<mailto:TLS@ietf.org> <mailto:tls@ietf.org>
Subject: Re: [TLS] Selfie attack was Re: Distinguishing between
external/resumption PSKs


On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"
<mailto:tls-bounces@ietf.orgonbehalfofmohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:

Hi all,

On the topic of external PSKs in TLS 1.3, I found a
publication on the
Selfie attack:
https://protect2.fireeye.com/url?k=dd432f13-81c9e5ad-dd436f88-869a17b5b21b-dc6c6f0a5dd21faf=1=https%3A%2F%2Feprint.iacr.org%2F2019%2F347

Perhaps this was already discussed on the list. I thought
that sharing
it again wouldn't hurt while we discuss how servers
distinguish between
external and resumption PSKs.

I just read the paper with interest. It occurs to me that the
selfie attack is consistent with the "impersonation attack" that we
reported on SPEKE in 2014; see S

[TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs

[Mohit Sethi M]

Hi all,

On the topic of external PSKs in TLS 1.3, I found a publication on the 
Selfie attack: https://eprint.iacr.org/2019/347

Perhaps this was already discussed on the list. I thought that sharing 
it again wouldn't hurt while we discuss how servers distinguish between 
external and resumption PSKs.

--Mohit

On 9/19/19 5:04 PM, Owen Friel (ofriel) wrote:
>
>> -Original Message-
>> From: Jonathan Hoyland 
>> Sent: 19 September 2019 14:32
>> To: Owen Friel (ofriel) 
>> Cc: Martin Thomson ; tls@ietf.org
>> Subject: Re: [TLS] Distinguishing between external/resumption PSKs
>>
>> Hi Owen,
>>
>> If I understand your question correctly the distinguishing is done implicitly
>> (not explicitly) through the key schedule.
>> If the client and server do not agree on whether the PSK is a resumption or
>> an OOB PSK then the `binder_key` will not match, and the handshake will fail.
>>
>> See pp. 93-94 of the spec.
> And we only even get that far on the off chance that an ext 
> PskIdentity.identity is exactly the same as a res PskIdentity.identity. e.g. 
> a client presents an ext PskIdentity.identity, the server somehow thinks it’s 
> a res PskIdentity.identity, and then handshaking will fail, not only because 
> the actual raw PSK is likely different but the binders will not match due to 
> different labels.
>
> But my question was before we even get that far - its an internal server 
> implementation decision how it determines whether the presented 
> PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB 
> table vs. a res cache first to find a PskIdentity.identity match. And say it 
> fails to find an ext match then it tries to find a res match, and if it finds 
> a match, then it knows what binder label to use.
>
>
>> Does that answer your question?
>>
>> Regards,
>>
>> Jonathan
>>
>> On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) 
>> wrote:
>>
>>> -Original Message-
>>> From: TLS  On Behalf Of Martin Thomson
>>> Sent: 04 September 2019 02:46
>>> To: mailto:tls@ietf.org
>>> Subject: Re: [TLS] Binder key labels for imported PSKs
>>>
>>>
>>> When we built the ext/res distinction, there was a clear problem
>> expressed.
>>> We had the potential for both to be used by the same servers at the same
>>> time (though not for the same connection) and distinguishing between
>> them
>>> was important
>> Martin, maybe I am missing something in the threads on this. Is there
>> anything explicit planned in ClientHello PreSharedKeyExtension or
>> PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
>> it up to server implementation and how the server handles the opaque
>> PskIdentity.identity? e.g. ImportedIdentity.external_identity fields could be
>> stored in one DB table, and (ignoring https://tools.ietf.org/html/draft-ietf-
>> tls-external-psk-importer-00#section-9 for now) the server on receipt of a
>> ClientHello searches for PskIdentity.identity in its
>> ImportedIdentity.external_identity  table and if that lookup fails, then try 
>> to
>> parse PskIdentity.identity  as a NewSessionTicket.ticket? And the order of
>> those two operations is of course implementation specific too.
>>
>>
>> ___
>> TLS mailing list
>> mailto: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] Distinguishing between external/resumption PSKs

[Mohit Sethi M]

Hi all,

Thanks Owen for starting this discussion. For some context, the EMU working 
group is currently working on a document titled "Using EAP-TLS with TLS 1.3": 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06

There has been recent discussion in the working group on whether EAP-TLS should 
support PSKs for the initial authentication. The current text says "Pre-Shared 
Key (PSK) authentication SHALL NOT be used except for resumption.".

As Richard points out, there is a distinction between "the server". Almost all 
EAP-TLS implementations use existing cryptographic libraries which handle the 
resumption PSK and PskIdentity. However, it is not clear (to me) who would set 
the PSKIdentity for the initial authentication. Should it be left to the 
application logic (in this case the EAP server)?

Do we care about PSKIdentity collisions? As Jonathan points out, having several 
PSKs with the same identity may require trial decryption and that can go wrong 
in several ways.

Chrisitian Huitema rightly points out that having free from PSKIdentity is good 
from a privacy perspective as an attacker cannot distinguish between initial 
authentication and resumption. However, if the server first has to lookup the 
resumption PSKs table before checking for any matching external PSKs, the 
timing information would leak that nonetheless.

Should a server issue NewSessionTickets when the original authentication itself 
was based on PSK? It would be nice to prevent tracking based on PSKIdentity.

We (or at least I) could certainly benefit with some more guidance from the TLS 
working group on this topic.

--Mohit

On 9/20/19 1:03 AM, Richard Barnes wrote:
On Thu, Sep 19, 2019 at 5:49 PM Nico Williams 
mailto:n...@cryptonector.com>> wrote:
On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote:
> I don't think anyone's asking for these cases to be differentiable on the
> wire.  The question is whether the *server* can differentiate, in
> particular, the application running on the server.

And the answer to that one is "yes", because the server has control over
the PSK IDs.

That glosses over an important distinction made up-thread: When we say "the 
server", there is typically a distinction between the TLS stack and the server 
application logic.  Resumption PSKs are typically controlled by the TLS stack, 
while external PSKs are provided by the application logic.  The question is how 
the application logic, when presented with a session authenticated under a 
given PSK ID, can distinguish whether the PSK used was one provided by the TLS 
stack for resumption, or provided by the application logic.

--Richard



___
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