Re: [TLS] Consultation About Assignment of ExtensionTypes

2020-06-19 Thread Salz, Rich
In my view, as one of the three designated experts, we already have the only 
channel we need, it's the "approved" column.

Anything else -- anything more -- runs counter to our principal of interop over 
all.


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


[TLS] something something certificate --- boiling a small lake

2020-06-19 Thread Michael Richardson

Brian,
{I have been on the httpbis list, but I'm not right now, and I know that
w3 and IETF do not share their whitelists, so this might not work}

I was thinking about something-something-certificate yesterday while 
cleaning/swimming
my pool.  (A long thankless task, as the pool is not heated, we've been
getting very a-seasonal *snow*, and nobody in my family but me will swim in it
until it's "perfect".  Also we have many many trees, which we won't cut down.
You can see how my mind might wander)

[This discussion would be better done with beer and napkins.]

So I am thinking that we need to create a "digital twin" in the back-end
server for the front-end TLS state machine.  It needs to reflect the current
state at a level of detail appropriate for the application.

Thus, a single header isn't enough, although there could be some degeneration
that results in a single header.  We need a few variables to update.

I think we have a choice between:

1) sending the state (possibly a few kb) on every transaction, which keeps
   the protocol stateless.  We could explore ways to encode it: CDDL+CBOR
   seems like a good thing.  TLS structures are another obvious choice, but
   that's a detail.

2) assuming that state will be maintained by both ends, and simply updating
   the state appropriately.   When it comes to this, I think of the
   HTTP PATCH methods, but I'm not sure I mean this literally.

It's the model of having a few objects per-connection that the TLS front-end
might update on the backend, and making the management of the TLS connections 
explicit.

Alternately, the TLS front-end could maintain a RESTful interface on a
per-connection basis that the back-end could interrogate.  The header
would just provide the right reference to that.  The RESTful interface
could even be pushed/updated into some other CPU on the TLS terminator.

This is cleaner, but this has read-latency round trip issues, while pushing
the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot more
pipelined.  Or MQTT :-)

To this, I think we'd have to look at the RFC8446 Appendix A.2 state machine
and figure out how to express this.   I don't really see re-auth in that
diagram.  Maybe I'm overthinking here, but given the opportunities in TLS
1.2 and 1.3 for newer states, and the review from TLS experts on the header,
this might be cleaner and less of a hack to get the additional things in.

This data model mechanism also better accomodates the split between those who
need the entire certificate chain (w/ and w/o trust anchor used), and those
that just care about the EE involved.

---

I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend
connection looks like.  I haven't entered such a world personally.

TLS front-end systems *are* collecting/storing state on a per-client
connection basis, whether the transport is QUIC or not.  I don't think it
scales well to try to spread that state across load balancers, you want to
split the traffic before the TLS terminators in order to horizontally scale
them.

A thought that I have is that with a move to HTTP/3, that the need for
something-something-certificate declines.
A model that I could see in such a situation is that since the bulk of the
transport is via QUIC, it could be that it makes less sense to have TLS
hardware terminators; by careful use of port numbers to demux upon, and/or
IPv6 addresses, it might be easier to load balance directly to application
servers, and just horizontally scale them wider.

The hardware TLS offload box then is only important for adapting HTTP 1
and HTTP/2 connections to HTTP/3.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Consultation About Assignment of ExtensionTypes

2020-06-19 Thread Salz, Rich
  *   It seems like it should appear with a "Recommended" value of "No", and no 
value in the TLS 1.3 column, since the document says "The Middlebox Security 
Protocol builds on TLS 1.2". [3]


  *   Is that what's being proposed?

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


Re: [TLS] Consultation About Assignment of ExtensionTypes

2020-06-19 Thread Rob Sayre
On Fri, Jun 19, 2020 at 11:02 AM Salz, Rich  wrote:

>
>- It seems like it should appear with a "Recommended" value of "No",
>and no value in the TLS 1.3 column, since the document says "The Middlebox
>Security Protocol builds on TLS 1.2". [3]
>
>
>
>- Is that what's being proposed?
>
>
>
> Yes.
>

I am in favor of this registration.

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


Re: [TLS] I-D Action: draft-ietf-tls-external-psk-guidance-00.txt

2020-06-19 Thread Sean Turner
Thanks to Chris for uploading the WG version of the draft.

If you have some time over the next couple of weeks please take the time to 
review this draft. The intent is to issue a WGLC after IETF 108 barring any 
discontent prior that.

spt

> On Jun 17, 2020, at 23:28, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
>Title   : Guidance for External PSK Usage in TLS
>Authors : Russ Housley
>  Jonathan Hoyland
>  Mohit Sethi
>  Christopher A. Wood
>   Filename: draft-ietf-tls-external-psk-guidance-00.txt
>   Pages   : 12
>   Date: 2020-06-17
> 
> Abstract:
>   This document provides usage guidance for external Pre-Shared Keys
>   (PSKs) in TLS.  It lists TLS security properties provided by PSKs
>   under certain assumptions and demonstrates how violations of these
>   assumptions lead to attacks.  This document also discusses PSK use
>   cases, provisioning processes, and TLS stack implementation support
>   in the context of these assumptions.  It provides advice for
>   applications in various use cases to help meet these assumptions.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-00
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-guidance-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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