Re: [TLS] Application-Layer Protocol Settings

[Martin Thomson]

Hi Victor,

For HTTP/2, this is essentially a noop, as endpoints are required to send 
SETTINGS immediately.  Whether these bytes appear before Finished or not only 
affects endpoints that aren't inclined to wait for SETTINGS.  This is somewhat 
complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we assume TLS 
1.3 here, any uncertainty is easily avoided.

The main justification here appears to be based on the lack of 0.5-RTT send 
capability at some servers.  I don't know how to assess whether the cost of 
greater integration with the TLS stack is preferable to fixing the 0.5-RTT send 
problem.

For HTTP/3, this has some incremental effect beyond that.  In effect, this 
deliberately introduces head-of-line blocking for settings.  You can already do 
that in HTTP/3 if you are not prepared to deal with settings being in an 
ambiguous state.  There's a little more determinism here in terms of where you 
look for the data that unblocks progress, but with retransmissions, this is not 
a difference worth worrying about.

What this head-of-line blocking might allow is the development of new 
extensions that are unable to deal with uncertainty regarding SETTINGS.  But 
isn't it also possible to address that problem by saying "if you implement 
extension X, then you MUST NOT send requests prior to receiving SETTINGS?"

In QUIC, we decided that having the server repeat its configuration after 0-RTT 
was preferable to remembering it.  This was after a non-trivial number of 
questions about that part of the specification.  You seem to have taken the 
opposite approach.  Is that deliberate?  If so, why?

On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote:
> Hello TLS and HTTP working groups,
> 
> (QUIC WG bcc'd as this has been discussed there before)
> 
> Currently, we use SETTINGS frames as an extensibility mechanism in 
> HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of 
> TLS application data; this approach, while simple, has some drawbacks. 
> The most notable one is that when SETTINGS are used to negotiate 
> extensions, there is an entire round-trip where the client can send 
> requests, but doesn't know yet about any server extensions, thus making 
> any extension-dependant requests take an extra RTT.
> 
> The proposed solution to this problem is to move HTTP SETTINGS frame 
> into the TLS handshake. Here are some issues where this has been 
> discussed before:
>  * https://github.com/quicwg/base-drafts/issues/3086
>  * https://github.com/quicwg/base-drafts/issues/3622
>  * https://github.com/WICG/client-hints-infrastructure/pull/30
> I wrote up a draft for the TLS extension that would solve this problem: 
> https://tools.ietf.org/html/draft-vvv-tls-alps-00
> 
> I also wrote up a draft that explains how to use that extension with 
> HTTP, and defines some settings (the ones discussed here 
> ) that would not be 
> possible without it: 
> https://tools.ietf.org/html/draft-vvv-httpbis-alps-00
> 
> I would appreciate feedback on those drafts.
> 
> Thanks,
>  Victor.
> ___
> 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] Application-Layer Protocol Settings

[Ben Schwartz]

Thanks for this draft.  I believe this is an important problem for HTTP
extensibility, and I'm glad to see work on a solution.

It occurs to me that this solution requires pretty tight integration
between the TLS termination and the HTTP backend.  Some TLS load balancers
already support ALPN, but they would have to be extended to support ALPS,
and I would worry about the potential for skew between the TLS terminator's
claimed settings and the backend's actual settings.

The draft says
   1.  While the server is technically capable of sending configuration
   to the peer as soon as it sends its Finished message, most TLS
   implementations do not allow any application data to be sent
   until the Finished message is received from the client.

Fixing this might require a change to some TLS implementations, but the
change to implement ALPS also seems significant.

The proposed 0-RTT interaction also seems like it would create a
significant risk of skew when a load balancer is in use, if the backend
settings can change.  Deployments that can't guarantee uniform backends
would have to disable 0-RTT (an unfortunate sacrifice for a feature that
saves 1 RTT!).

For load balancers, or any other situation where TLS and HTTP are loosely
coupled, sending SETTINGS at 0.5-RTT would seem like a much simpler
solution.  I know the draft mentions a few cases where this doesn't work
well, but perhaps there's a middle ground of some sort.  For example:

* If supporting generic 0.5-RTT forwarding is hard, TLS server
implementations could offer a configuration to send an arbitrary fixed
buffer at 0.5-RTT (depending on ALPN).  No standards change is required.
* The application protocol (here HTTP) could indicate what state is
guaranteed to persist across session resumption.  Although the preserved
state here (SETTINGS) is ~static, in general this could include dynamic
session state too.  This would move the change to HTTP, instead of TLS.

On Mon, Jul 6, 2020 at 3:13 PM Victor Vasiliev  wrote:

> Hello TLS and HTTP working groups,
>
> (QUIC WG bcc'd as this has been discussed there before)
>
> Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2
> and HTTP/3.  The SETTINGS frame is sent at the very beginning of TLS
> application data; this approach, while simple, has some drawbacks.  The
> most notable one is that when SETTINGS are used to negotiate extensions,
> there is an entire round-trip where the client can send requests, but
> doesn't know yet about any server extensions, thus making any
> extension-dependant requests take an extra RTT.
>
> The proposed solution to this problem is to move HTTP SETTINGS frame into
> the TLS handshake.  Here are some issues where this has been discussed
> before:
>
>- https://github.com/quicwg/base-drafts/issues/3086
>- https://github.com/quicwg/base-drafts/issues/3622
>- https://github.com/WICG/client-hints-infrastructure/pull/30
>
> I wrote up a draft for the TLS extension that would solve this problem:
> https://tools.ietf.org/html/draft-vvv-tls-alps-00
>
> I also wrote up a draft that explains how to use that extension with HTTP,
> and defines some settings (the ones discussed here
> ) that would not be
> possible without it: https://tools.ietf.org/html/draft-vvv-httpbis-alps-00
>
> I would appreciate feedback on those drafts.
>
> Thanks,
>   Victor.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

Dear WG,

I've taken a look at the draft and I think while its discussion of the
properties and limitations of the external PSKs are good, I think the
recommendations in section 7 could use some minor editorial work.

In particular  "SHOULD be combined with a DH exchange for forward
secrecy." I would like to see rephrased to make clear that this is
about the TLS PSK Key Exchange Mode. It wasn't immediately clear to me
on first read, especially given the next sentence is (maybe) about key
establishment outside of TLS.

"If only low-entropy keys are available, then key establishment
mechanisms such as Password Authenticated Key Exchange (PAKE) that
mitigate the risk of offline dictionary attacks SHOULD be employed".
I have some questions about the meaning of this sentence. If it's
about potential future additions to TLS ciphersuites, then it should
be more clear that this doesn't currently exist and will in the
future.  If it's about designing an ad-hoc key distribution mechanism
to be run one time ahead of PSK TLS, then I think we should say so
more clearly and provide guidance on how to do this and think through
the implications.

Section 7.1.1. While it's a good idea to compare byte by byte, humans
entering PSK identifiers may run into trouble due to all the ways
visually identical strings may not actually be identical. It might be
worth calling this out as a consideration.

Sincerely,
Watson Ladd

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

[TLS] Application-Layer Protocol Settings

[Victor Vasiliev]

Hello TLS and HTTP working groups,

(QUIC WG bcc'd as this has been discussed there before)

Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2
and HTTP/3.  The SETTINGS frame is sent at the very beginning of TLS
application data; this approach, while simple, has some drawbacks.  The
most notable one is that when SETTINGS are used to negotiate extensions,
there is an entire round-trip where the client can send requests, but
doesn't know yet about any server extensions, thus making any
extension-dependant requests take an extra RTT.

The proposed solution to this problem is to move HTTP SETTINGS frame into
the TLS handshake.  Here are some issues where this has been discussed
before:

   - https://github.com/quicwg/base-drafts/issues/3086
   - https://github.com/quicwg/base-drafts/issues/3622
   - https://github.com/WICG/client-hints-infrastructure/pull/30

I wrote up a draft for the TLS extension that would solve this problem:
https://tools.ietf.org/html/draft-vvv-tls-alps-00

I also wrote up a draft that explains how to use that extension with HTTP,
and defines some settings (the ones discussed here
) that would not be
possible without it: https://tools.ietf.org/html/draft-vvv-httpbis-alps-00

I would appreciate feedback on those drafts.

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

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

[Jim Schaad]

> -Original Message-
> From: Mohit Sethi M 
> Sent: Monday, July 6, 2020 3:10 AM
> To: Jim Schaad ; draft-ietf-tls-external-psk-
> guida...@ietf.org
> Cc: 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.

> 
> 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'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] 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