Re: [TLS] Flags Extension: why only for TLS 1.3?

[Thomas Fossati]

hi John,

On Thu, Nov 4, 2021 at 1:11 PM John Mattsson  wrote:

> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines
> obsolete as "no longer produced or used; out of date." NIST requires
> support of TLS 1.3 everywhere no later than Jan 2024, which at least in
> theory means no negotiation of TLS 1.2.
>
>
>
> I think IETF, TLS WG, and TLS libraries should spend their time on TLS
> 1.3 rather than giving the false idea it is ok to stay on TLS 1.2.
>

Whilst I agree on the general sentiment, let me point out that the specific
extension we wanted to register (RRC) would be DTLS-only.

And while deprecating TLS 1.2 is certainly OK since 8446 has been around
for 3+ years, the deprecation of DTLS 1.2 would seem a tad premature absent
a published RFC for 1.3 (*)

cheers!

(*) This is going to change soon, but it'll take time for implementations
to catch up (**)

(**) IoT is a vastly different space compared to telco and web.  It is very
fragmented with no real incumbents that could orchestrate a quick
switchover.  Also, because of the heterogeneity of platforms there is a
very high number of purpose built stacks.  So we need to be a bit more
patient (***)

(***) Nothing, just checking if you are still following me in this meander
of recursive footnotes ;-)



> John
>
>
>
> *From: *TLS  on behalf of Hannes Tschofenig <
> hannes.tschofe...@arm.com>
> *Date: *Monday, 25 October 2021 at 19:12
> *To: *IETF TLS 
> *Subject: *[TLS] Flags Extension: why only for TLS 1.3?
>
> Hi all,
>
>
>
> why is the flags extension only defined for TLS 1.3?
>
>
>
> There is nothing in this extension that prevents us from using it also in
> TLS 1.2.
>
>
>
> Could we make it also available to TLS 1.2?
>
>
>
> Ciao
>
> Hannes
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


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

[TLS] ECH - handling retry config with different public name?

[Stephen Farrell]

Hiya,

Bit of a corner case I'm not sure about. Apologies
if this has come up before.

The scenario:

- inner SNI is inner.example
- ECHConfig from inner.example's DNS has outer.example
  as public_name
- client authenticates with ClientHelloOuter and the
  ServerHello contains retry_configs with one ECHConfig
  that has a public_name of another.example
- client decides to retry and a similar thing happens
  (authenticates with ClientHelloOuter) but this time
  with public_name of yetanother.example
- rinse/repeat until the client is fed up with retries
  or manages to authenticate using ClientHelloInner if
  ECH eventually works

My question is: should the client care about those
changes in public_name or not? I think the answer is
"not" but wanted to check.

Ta,
S.






OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH - handling retry config with different public name?

[David Benjamin]

That's my inclination as well. It's an odd thing for a server to do, but it
seems fine to just retry with the new config without much fuss?

On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> Bit of a corner case I'm not sure about. Apologies
> if this has come up before.
>
> The scenario:
>
> - inner SNI is inner.example
> - ECHConfig from inner.example's DNS has outer.example
>as public_name
> - client authenticates with ClientHelloOuter and the
>ServerHello contains retry_configs with one ECHConfig
>that has a public_name of another.example
> - client decides to retry and a similar thing happens
>(authenticates with ClientHelloOuter) but this time
>with public_name of yetanother.example
> - rinse/repeat until the client is fed up with retries
>or manages to authenticate using ClientHelloInner if
>ECH eventually works
>
> My question is: should the client care about those
> changes in public_name or not? I think the answer is
> "not" but wanted to check.
>
> Ta,
> S.
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

[Jonathan Hoyland]

Hi Simo,

As I said in my email to Sam, my language here was sloppy, I meant that the
channel binding is included in the key derivation process, and thus the
output keys will be related to each other.
The term channel bindings has two different meanings using in very similar
contexts, which leads to great confusion and is why I prefer the term
compound authentication (see Chapter 4.4 of my thesis)
.

A channel binding is a "name" of a channel as you say, but it is also used
to mean using one channel to authenticate another.
Very specifically if channel `a` is bound to channel `b` then that means
that if channel `b` is securely authenticated then channel `a` was formed
honestly (i.e. even if all of the long term key material for channel `a`
has been leaked, I can be sure that my channel `a` peer is the same actor
as my channel `b` peer.)

Channel bindings that aren't bound to a specific session are less secure
than ones that are, so yes, you can use them, but that doesn't mean they
have the security properties you need.
The purpose of binding a protocol to an underlying TLS session is to
leverage some of the security guarantees offered by the TLS layer.
If those guarantees are never necessary because the over-the-top protocol
is always perfectly secure, just run the protocol on the wire and drop the
TLS complication.
If those guarantees are at least sometimes necessary then you need to
securely bind the two channels together.

Channel binding does more than simply guarantee that the messages were the
same, it also guarantees that the identity of the actors at each layer
remains the same, and that the keys derived in each layer match.
With an appropriately designed channel binding you can use TLS's protection
against MITM attacks to protect insecure protocols run over the top.
Having now looked at SCRAM a little bit, using the TLS channel binding
guarantees that some malicious server isn't passing the client's messages
off to another server and performing a malicious authentication there.
Using a unique string from SCRAM means that messages from some other
protocol won't be compatible.
If you don't require a unique string I could write a new protocol SCRAM++
with cross-compatible messages, but different security guarantees, and use
that to compromise SCRAM clients.
Obviously that's a patently malicious example, but it's perfectly possible
that some new version of SCRAM produces messages that an old version of
SCRAM misinterprets.
It's even highly likely that a server that supports old versions of SCRAM
for backwards compatibility would use the same key material for all
versions.

Requiring a unique string makes the messages totally unrelated.

I don't find the arguments "It's always been insecure in the past" or "We
have bad APIs" especially compelling.

Regards,

Jonathan


On Fri, 29 Oct 2021 at 14:55, Simo Sorce  wrote:

> Hi Jonathan,
>
> On Thu, 2021-10-28 at 18:46 +0100, Jonathan Hoyland wrote:
> > Hi Ruslan,
> >
> > Yes, two distinct TLS connections having the same exporter key would be
> > really bad, but I'm specifically talking about two runs of some protocol
> > bound to a single TLS session.
> > A single TLS session will return the same key (modulo rekeying,
> resumption
> > etc.) if you call the Exporter API with the same label.
> > This means that the channel bindings it produces, which will then be used
> > to derive the keys of the higher layer protocol, will produce related
> keys.
> >
> > The key reason for making the binding retrieval context-specific is to
> make
> > sure that different protocols run in the same TLS session produce
> disjoint
> > keys.
>
> Note, Channel Bindings are *not* a key and should never used as such,
> so I think you are using a false premise here.
> Channel Bindings are, at most, a unique value associated with a session
> (keep in mind that often Channel Bindings do not even bind to a
> specific session, see 'tls-server-end-point' which is used in
> preference in many cases within HTTPS endpoints because of the way
> server termination is built in some scalable architectures).
>
> > When someone tries to copy a message from a SCRAM handshake into some
> > GSS-API run on a single TLS connection I want to be sure that it will be
> > rejected, without having to understand exactly how every version of SCRAM
> > and GSS-API ever (including ones that will be drafted in the future)
> works
> > (not to mention every other protocol past, present, and future that uses
> > the same string.)
>
> Both SCRAM and GSS-API are authentication mechanisms that use shared
> keys for authentication. Both protocols are inherently resistant to
> message swapping because the chances of producing a message on one
> protocol that can be successfully decrypted/HMACed on the other are
> astronomically low (they must be or the protocols are broken).
>
> Channel bindings are just a way to tie those authentications to 

[TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

[Hanno Becker]

Hi all,

Both DTLS 1.2 and DTLS 1.3 mandate:

> When a DTLS implementation receives a handshake message fragment 
> corresponding to the next expected handshake message sequence number, it MUST 
> buffer it until it has the entire handshake message.

Can someone explain the underlying rationale?

It seems that in the context of very large key material or certificate
chains (think e.g. PQC), gradual processing of handshake messages
(where possible) is useful to reduce RAM usage.
Is there a security risk in doing this?

It would also be useful for stateless handling of fragmented
ClientHello messages. I'm sure this was discussed before but
I don't remember where and who said it, but a server implementation
could peek into the initial fragment of a ClientHello, check if it
contains a valid cookie, and if so, allocate state for subsequent full
reassembly. That wouldn't be compliant with the above MUST, though,
as far as I understand it.

Thanks!
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

[Ruslan N. Marchenko]

Hi Jonathan,

Am Freitag, dem 05.11.2021 um 15:34 + schrieb Jonathan Hoyland:
> 
> Having now looked at SCRAM a little bit, using the TLS channel
> binding guarantees that some malicious server isn't passing the
> client's messages off to another server and performing a malicious
> authentication there.
> ...
> If you don't require a unique string I could write a new protocol
> SCRAM++ with cross-compatible messages, but different security
> guarantees, and use that to compromise SCRAM clients. 
> Obviously that's a patently malicious example, but it's perfectly
> possible that some new version of SCRAM produces messages that an old
> version of SCRAM misinterprets. 
Authentication method and SCRAM mechanism negotiation must happen
before SCRAM exchange. if parties don't agree on the method/mechanism
negotiation fails. If you control the server to the level that you
negotate one method/mechanism but use another - you're not mitm, you
just _pwn_ the service, and no binding in the world would solve that.
> It's even highly likely that a server that supports old versions of
> SCRAM for backwards compatibility would use the same key material for
> all versions. 
> 
> Requiring a unique string makes the messages totally unrelated. 
> 
> I don't find the arguments "It's always been insecure in the past" or
> "We have bad APIs" especially compelling. 
> 
It's not "historically insecure", it's just not a secret key by design.
It's public (non-secret) but unique and imutable property of the TLS
channel (not application/authentication channel, mind you). Finished
packet - is not a secret - any sneaky person can snoop it. Certificate
digest - is not a secret, any person in the world can get it. It's not
a guardian of the confidentiality, rather a warrant of integrity.


Regards,
Ruslan


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