Re: [TLS] CertficateRequest extension encoding

[Martin Rex]

Geoffrey Keating wrote:
> 
> A typical macOS system will have many issued certs, typically with at
> most one that will work for any particular web site or web API.  So
> the filter is somewhat important for client certs to work there in any
> kind of user-friendly way.  In particular if the server provides no
> guidance, the UI will ask the user, presenting a dialog containing
> many certificates the user is not aware they have, leading to complete
> user confusion.

In the past, Safari on MAC entirely ignored the server-asserted contents of
certificate_authorities in the TLS CertificateRequest handshake message,
and would offer *all* possible client certs to the user.  Has this
bug been fixed in Safari?  I remember customer messages where clients
were refused that were erroneously sending AppleID client certs...


-Martin

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

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

[Filippo Valsorda]

2016-10-07 22:06 GMT+ David Benjamin :
> Units is a little interesting. For those purposes, this limit would
> kick in whether or not the early data could be decrypted, so the server-
> side limit would be measured in ciphertext, possibly even including
> record headers. (Although any inaccuracies in converting could be done
> by just advertising an underestimate and breaking peers that send
> pathologically silly things like all one-byte records. So it doesn't
> matter much.)

Yeah, I've been thinking about that. I went for plaintext because it
seemed to simplify the API on the client side, but maybe it's best to
count  the whole record size, and let the client worry about not doing
some silly splitting or padding.

I'll update the PR.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Watson Ladd]

On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin  wrote:
> To add to that, in out-of-order transports, whether a message was sent over
> 0-RTT or not may not even be very well-defined. If QUIC originally sent data
> over 0-RTT but had to retransmit it after the full connection parameters are
> available, I believe it will use those.
>
> Even in an in-order transport, imagine if I have a very long replayable
> request in HTTP/2 (maybe it's a PUT and comes with a request body, or maybe
> it has too many headers). I start sending that one over 0-RTT. While I'm in
> the middle of sending that, I get back a ServerHello (w/ early_data) through
> Finished. I either need to complete the handshake and switch to 1-RTT
> mid-request or wait for the long request to complete before finishing the
> handshake or sending any non-replayable ones, though they may be higher
> priority. (They probably are if they don't come with as giant of response
> bodies...) The former is by far the more attractive option.
>
> Or perhaps I hit max_early_data_size
> (https://github.com/tlswg/tls13-spec/pull/674) and thus can't send more
> 0-RTT data anyway.
>
> In HTTP/2 you have the additional amusement that, due to HPACK, your 0-RTT
> data probably has an effect on the 1-RTT data even if requests are all or
> nothing.
>
> I don't think we can make the receiver aware of the 0-RTT / 1-RTT boundary
> sanely. In my mind, the decision whether to send something 0-RTT or wait
> until 1-RTT is primarily the sender's business. If the sender wanted to, it
> could make the data replayable anyway by just replaying it. On the
> receiver's side, yeah, you concatenate the streams. That's why the server
> must decline 0-RTT if any negotiated parameter (ALPN, etc.) changes.

The problem is with poorly-behaved senders and attackers resending
0-RTT data. Receivers should be able to ensure side-effectfull
operations are not carried out by 0-RTT data. Making 0-RTT silent in
APIs transforms an interoperability issue into a silent security
issue. This is not a good idea.

>
> David
>
>
> On Sat, Oct 8, 2016 at 1:14 PM Nick Harper  wrote:
>>
>> In my proposed 0-RTT Token Binding draft
>> (https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01), the
>> signature is the same in 0-RTT data as in 1-RTT data, assuming the server
>> didn't reject early data. The thought here is that a client's write API
>> might look like "please send this data, and I'm fine with it being sent
>> 0-RTT", so the Token Binding code doesn't have to know if its message was
>> sent before or after handshake completion. If early data is rejected, then
>> the application data has to change, but this isn't something limited to
>> Token Binding. A server cold reject early data and also change ALPN from
>> what the client expected, requiring the client to send different data.
>>
>> I think it's fine from an API perspective for data sent 0-RTT to also be
>> sent 1-RTT so long as early data is accepted.
>>
>>
>> On Saturday, October 8, 2016, Ilari Liusvaara 
>> wrote:
>>>
>>> On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote:
>>> > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara
>>> > 
>>> > wrote:
>>> >
>>> > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
>>> > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
>>> > > >  wrote:
>>> > > > >
>>> > > > > Also, it is very likely that 0-RTT would need its own read API,
>>> > > > > because
>>> > > > > it is pretty unlikely that existing API could be safely
>>> > > > > retrofitted
>>> > > > > or even purpose-built unified API be designed that isn't just
>>> > > > > asking
>>> > > > > for security problems via mixing 0-RTT and 1-RTT data.
>>> > > >
>>> > > > Yes. In particular I think the TLS state machine transitions need
>>> > > > to
>>> > > > be ordered with respect to the arrival and sending of data. The
>>> > > > challenge for a multithreaded program (yes, some programs have
>>> > > > multiple threads sending and receiving at once) is making this make
>>> > > > sense, or even a single-threaded program where the TLS stack can
>>> > > > change state at times not visible to the sending thread. Maybe
>>> > > > there
>>> > > > is some slop here, like 0-RTT can become 1-RTT on send, but this
>>> > > > raises all sorts of problems for receiving. I think we need to
>>> > > > require
>>> > > > separation in the API.
>>> > >
>>> > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto-
>>> > > retransmit, which needs to be disableable, as sometimes that just
>>> > > plain
>>> > > won't work).
>>> >
>>> > Can you explain why that is?
>>>
>>> E.g. what they are planning to do with 0-RTT Token Binding in HTTP.
>>> The client puts in a signature into 0-RTT data. If the server rejects
>>> the 0-RTT and the client retransmits, the signature will still be
>>> there but is different.
>>>
>>> Also, if 0-RTT data can silently shift to 1-RTT, it would mean the
>>> server-side model would be to concatenate 0-RTT and

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

[Eric Rescorla]

Merged

On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla  wrote:

> I agree that this is a good idea. Absent objection, i'm going to merge
> this PR on Monday
>
> On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin 
> wrote:
>
>> We were also expecting to want to bound how much traffic a server could
>> be compelled to skip over without making progress. It actually didn't occur
>> to me we could let the client know the bounds, rather than just making up a
>> conservative bound (there's only so much data you can get into an RTT) and
>> hoping nothing breaks. That's a good idea.
>>
>> Units is a little interesting. For those purposes, this limit would kick
>> in whether or not the early data could be decrypted, so the server-side
>> limit would be measured in ciphertext, possibly even including record
>> headers. (Although any inaccuracies in converting could be done by just
>> advertising an underestimate and breaking peers that send pathologically
>> silly things like all one-byte records. So it doesn't matter much.)
>>
>> On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk  wrote:
>>
>>> On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
>>>
>>> Hello,
>>>
>>> Cloudflare's current (not definitive) plan for 0-RTT is essentially to
>>> decide whether or not to answer to requests in the 0.5 flight on a
>>> case-by-case basis. That obviously requires reading all of them and
>>> caching the ones we don't want to answer.
>>>
>>> To mitigate the obvious DoS concern we plan to use the ticket age and a
>>> per-machine replay cache.
>>>
>>> However, chatting with Drew (cc'd) we realized that clients could still
>>> send huge amounts of 0-RTT data that we would have to buffer. Once a
>>>
>>>
>>> Well, "have to" is perhaps a bit of a stretch; the client should be
>>> prepared to cope reasonably if you abort the connection arbitrarily.
>>>
>>
>> I think the concern is that a well-meaning client may not necessarily do
>> a retry here and instead read this even as a network error. And if it did,
>> the next attempt, if there is still a 0-RTT-able ticket available, may hit
>> this again anyway...
>>
>> client sent early data, there's no way to accept only a part of it or to
>>> verify that the client is not replaying before reading it all. But if we
>>> were to close the connection after a given amount of data we risk
>>> failing connections from legal clients.
>>>
>>> I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
>>> inform clients about the maximum amount of 0-RTT data they are allowed
>>> to send, allowing servers to safely terminate connections that exceed
>>> it.
>>>
>>>
>>> But this seems like a good idea; I left a couple of ~editorial notes on
>>> github.
>>>
>>> -Ben
>>>
>>>
>>> https://github.com/tlswg/tls13-spec/pull/674
>>>
>>> [Please keep me in the CC of replies]
>>>
>>> ___
>>> TLS mailing listTLS@ietf.orghttps://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] Application layer interactions and API guidance

[Kyle Rose]

On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd  wrote:

>
> The problem is with poorly-behaved senders and attackers resending
> 0-RTT data. Receivers should be able to ensure side-effectfull
> operations are not carried out by 0-RTT data. Making 0-RTT silent in
> APIs transforms an interoperability issue into a silent security
> issue. This is not a good idea.
>

+1.

FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
that the web is substantially broken without retry logic in the browsers,
that naturally make application-level replay mitigation a necessity. But I
don't think (nor do I think he claimed) that the same is true of all
protocols or systems that might use TLS. So while 0-RTT-obliviousness may
be okay for browsers in particular given the other constraints under which
they operate, it is probably not good to bake that into the API for the
general case.

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

Re: [TLS] Zero-RTT Data & PSK

[Eric Rescorla]

I agree with MT. Hannes, if you want to clean up the text to take into
account MT's comments, I will merge

On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson 
wrote:

> On 9 September 2016 at 23:37, Hannes Tschofenig
>  wrote:
> > I am wondering why I cannot use Zero-RTT with just PSK-based
> authentication
> > (without a prior ticket change).
>
> I think that you would need to bind more things to the key in that
> case, but I assume that it would be OK if you did so.  You already
> need to pair a PSK with a hash, but if you paired it with a whole
> cipher suite instead and also the ALPN (which could be null), then I
> see no reason not to permit 0-RTT for pure PSK.  (I think that cipher
> suite + ALPN is sufficient, but someone can correct me if I missed
> anything.)
>
> ___
> 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] Making post-handshake messages optional in TLS 1.3 (#676)

[Benjamin Kaduk]

With respect to communicating policy from the application layer to the
TLS stack, what's wrong with David's "CertificateRequest is disallowed
by default, and the application must make a library call to enable it
for a given connection/context" proposal?  It seems fairly
straightforward in terms of API surface, to me.

You mostly mentioned this already, but this list of known message types
is another protocol surface that would need to be GREASEd.

So, on the balance, I think I'm starting to lean against this specific
proposal and more towards the text changes that David wants.

-Ben

On 10/08/2016 03:02 PM, Nick Sullivan wrote:
> I agree that "I don't like NST or KU" is not a very useful thing to
> add to the spec. I added them as part of a general move towards
> clarity and conservatism about which types of post-handshake messages
> are permissible in TLS 1.3. Right now the spec is ambiguous about what
> each side of the connection is supposed to do when it receives an
> unexpected or unknown post-handshake message. This change hopefully
> makes it crystal clear: any post-handshake message that wasn't agreed
> upon by both parties should be fatal.
>
> David suggested that the behavior with respect to post-handshake
> messages should be negotiated at the application layer. This also
> seems reasonable, but I worry about how this policy would be
> communicated from the application layer to the TLS stack. Would the
> application layer be alerted of incoming CertificateRequests and
> either terminate the connection or reply with an empty certificate and
> finished message? If we want to support "2018" post-handshake
> messages, will we just end up re-inventing this post_handshake
> extension in a later draft to advertise support? Different
> post-handshake messages have different uses, so I see how this more
> case-by-case application-dependent policy could be more expressive
> than what I proposed, but I worry we may end up with something more
> complex than necessary.
>
> In any case, post-handshake authentication as currently described is
> problematic. I'd be open to seeing a text change along the lines of
> what David proposed instead of the wire change I'm proposing as long
> as it includes some guidance around how it should interact with
> policies from the application layer.
>
>
>
> On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla  > wrote:
>
> I could go either way on this. It seems like this pushes
> complexity from the client to the server. 
>
> Consider the case of NST. Presently, a client which doesn't want
> resumption can just ignore NST,
> but in your proposed change, the server needs to read this
> extension and then conditionally send
> NST, and the client still needs the logic to detect unexpected
> handshake messages and abort
> on them.
>
> As I said, I could go either way, and I do think it's potentially
> useful to be able to say "I won't do
> post-handshake client auth" and even more useful to be able to say
> "I would do post handshake
> message X which will be invented in 2018" (but of course we can
> register an extension for
> that then), but less useful to say "I don't like NST or KU"
>
> -Ekr
>
>
> On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan
> mailto:nicholas.sulli...@gmail.com>>
> wrote:
>
> I'm not proposing any new post-handshake authentication
> mechanisms or anything relating to HTTP/2 renegotiation in
> this change. I'm simply making support for the existing
> post-handshake messages optional.
>
> With this change, if the client does not opt in, unexpected
> CertificateRequests are fatal to the connection. Same with
> unexpected KeyUpdates and SessionTickets. This will hopefully
> reduce the complexity of TLS 1.3 implementations that don't
> need these features.
>
> Nick
>
> On Sat, Oct 8, 2016 at 8:06 AM David Benjamin
> mailto:david...@chromium.org>> wrote:
>
> On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
>  > wrote:
>
> On Sat, Oct 08, 2016 at 01:03:21AM +, Nick
> Sullivan wrote:
>
> > There has been a lot of discussion lately about
> post-handshake messages
>
> > that do not contain application data and how to
> handle them. This PR is an
>
> > attempt to make the story more explicit by adding a
> new post_handshake
>
> > extension to TLS 1.3.
>
> >
>
> > Supporting all types of post-handshake messages can
> require extra
>
> > complexity and logic, even when the features that
> these messages enable are
>
> > not needed. Some types of
> connections/imp

Re: [TLS] Application layer interactions and API guidance

[Martin Thomson]

On 11 October 2016 at 07:57, Kyle Rose  wrote:
> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
> that the web is substantially broken without retry logic in the browsers,
> that naturally make application-level replay mitigation a necessity. But I
> don't think (nor do I think he claimed) that the same is true of all
> protocols or systems that might use TLS. So while 0-RTT-obliviousness may be
> okay for browsers in particular given the other constraints under which they
> operate, it is probably not good to bake that into the API for the general
> case.

The 0-RTT API in NSS allows a server to detect this transition.  The
problem that I think David was referring to is that the specific
instant of the transition is lost when the multiple layers of stack
that sit on top of TLS get involved.

If an HTTP client sends a request that relies on HPACK state that was
established during 0-RTT, is it a 0-RTT request?  I'm going to go with
probably not.

If an HTTP client sends the first octets of a message in 0-RTT but
completes the request after the handshake completes, is it 0-RTT?  I
suspect that this again is not a concern.

I agree that we should make it clear that 0-RTT data needs to be
treated specially.  I would like to see someone propose some text
rather than read more vague emails on the subject.

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

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Martin Thomson]

On 11 October 2016 at 14:30, Benjamin Kaduk  wrote:
> So, on the balance, I think I'm starting to lean against this specific
> proposal and more towards the text changes that David wants.

Yes, I would rather not take NST or KU out of the mandatory set of 1.3
features.  I'm happy to have post-handshake authentication require
opt-in though.

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