[TLS] [Technical Errata Reported] RFC7250 (5013)
The following errata report has been submitted for RFC7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5013 -- Type: Technical Reported by: i Section: 7 Original Text - IANA has allocated two new TLS extensions, client_certificate_type and server_certificate_type, from the "TLS ExtensionType Values" subregistry defined in [RFC5246]. Corrected Text -- IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for client_certificate_type and server_certificate_type, respectively, in the "TLS ExtensionType Values" subregistry defined in [RFC5246]. Notes - Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7250 (draft-ietf-tls-oob-pubkey-11) -- Title : Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Publication Date: June 2014 Author(s) : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen Category: PROPOSED STANDARD Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC7250 (5013)
I would definitively re-categorize this “editorial”; there’s no 2119-changes proposed and there’s no bits on the wire changes. And, I’d either reject this one because technically the existing text is correct (i.e., they are two extensions) and this really ought not of caused an interoperability problem or mark it HFDU (hold for document update). The new text does include the code points, but those can be obtained from the registry and don’t absolutely have to be included. spt > On May 10, 2017, at 02:45, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7250, > "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram > Transport Layer Security (DTLS)". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5013 > > -- > Type: Technical > Reported by: i > > Section: 7 > > Original Text > - > IANA has allocated two new TLS extensions, client_certificate_type > and server_certificate_type, from the "TLS ExtensionType Values" > subregistry defined in [RFC5246]. > > Corrected Text > -- > IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for > client_certificate_type and server_certificate_type, respectively, > in the "TLS ExtensionType Values" subregistry defined in [RFC5246]. > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC7250 (draft-ietf-tls-oob-pubkey-11) > -- > Title : Using Raw Public Keys in Transport Layer Security (TLS) > and Datagram Transport Layer Security (DTLS) > Publication Date: June 2014 > Author(s) : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. > Weiler, T. Kivinen > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC7250 (5013)
On Wed, 10 May 2017, Sean Turner wrote: I would definitively re-categorize this “editorial”; there’s no 2119-changes proposed and there’s no bits on the wire changes. And, I’d either reject this one because technically the existing text is correct (i.e., they are two extensions) and this really ought not of caused an interoperability problem or mark it HFDU (hold for document update). The new text does include the code points, but those can be obtained from the registry and don’t absolutely have to be included. Sounds right to me. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Alerts
Draft-20 currently contains this text in the section "Server Certificate Selection": 'If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an"unsupported_certificate" alert."' However, section 6 lists a number of other generic certificate related alerts: certificate_revoked certificate_expired certificate_unknown unknown_ca While section 6 provides descriptions of these they are not mentioned elsewhere in the spec, so there is no guidance as to when they might be used. So, given the text in the "Server Certificate Selection" section, should a client always send "unsupported_certificate" for all failures? Or should one of the other alerts be used instead if it seems more appropriate? E.g. If a client attempts to "construct an acceptable chain", but finds an expired certificate - should it respond with "unsupported_certificate" or "certificate_expired"? There seems to be some inconsistency between server certificate selection and client certificate selection, i.e. in the former it is mandated that a specific alert be sent, but in the latter there is no such requirement. Additionally, there are a number of other alerts mentioned in section 6 (not just certificate related ones), that are never mentioned anywhere else in the spec. Do we really need all of these alerts? If they are needed, shouldn't they be explicitly mentioned elsewhere in the spec in the locations where they are relevant (associated with some MUST/SHOULD/MAY requirement)? As things stand the interpretation of when they should be sent seems quite loose. Matt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] "Encrypted" SNI
Yes, encrypted SNI was discussed and ultimately rejected. But do we really have to send the literal value? Don't we need to just make sure that the client and server agree on the host that the client wants to connect? Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending the salt and the resulting hash, making the server calculate the same hash with each of the virtual host names it supports and comparing with the client provided value? (apologies if that was already proposed and rejected) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
> On May 10, 2017, at 1:28 PM, Hubert Kario wrote: > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending > the salt and the resulting hash, making the server calculate the same hash > with each of the virtual host names it supports and comparing with the client > provided value? > > (apologies if that was already proposed and rejected) There in many cases way too many virtual host names for the server to test. On the other hand, the attacker with fast hashing silicon can perform the same computation very quickly. The virtual hosts supported by the remote server are likely not much a secret in most cases. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote: > > On May 10, 2017, at 1:28 PM, Hubert Kario wrote: > > > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, > > sending > > the salt and the resulting hash, making the server calculate the same hash > > with each of the virtual host names it supports and comparing with the > > client provided value? > > > > (apologies if that was already proposed and rejected) > > There in many cases way too many virtual host names for the server to test. if you have tens of thousands of websites you either have a farm of servers, so you can solve that with sharding, or the websites don't get much traffic so it's not a performance problem > On the other hand, the attacker with fast hashing silicon can perform the > same computation very quickly. But it does make simple keyword matching on hostname much harder or impossible. > The virtual hosts supported by the remote > server are likely not much a secret in most cases. that's argument for not spending too much resources on the encryption/ obfuscation, not that we shouldn't do it. But in general, I wonder if we didn't approach the SNI from the wrong side - as I said, we may not need to encrypt it, we just make sure that client and server agree on the virtual host the connection is going to. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
> On May 10, 2017, at 2:47 PM, Hubert Kario wrote: > > But in general, I wonder if we didn't approach the SNI from the wrong side - > as I said, we may not need to encrypt it, we just make sure that client and > server agree on the virtual host the connection is going to. They can do that with a name in the clear. If the name is to be hidden from passive observers, then you do need encryption so that only the client and server, and not the passive observers, can recover the name. Encryption means key agreement, and requires delaying SNI by a round-trip, or having published DH shares in DNS, which of course also needs privacy protection for SNI encryption to matter. I do believe this was discussed at some length previously. -- -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
> Encryption means key agreement, and requires delaying SNI by a round-trip, > or having published DH shares in DNS, which of course also needs privacy > protection for SNI encryption to matter. With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible. A am long overdue for a writeup on this. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On 5/10/2017 12:04 PM, Viktor Dukhovni wrote: >> On May 10, 2017, at 2:47 PM, Hubert Kario wrote: >> >> But in general, I wonder if we didn't approach the SNI from the wrong side - >> as I said, we may not need to encrypt it, we just make sure that client and >> server agree on the virtual host the connection is going to. > They can do that with a name in the clear. If the name is to be hidden > from passive observers, then you do need encryption so that only the > client and server, and not the passive observers, can recover the name. > > Encryption means key agreement, and requires delaying SNI by a round-trip, > or having published DH shares in DNS, which of course also needs privacy > protection for SNI encryption to matter. > > I do believe this was discussed at some length previously. It certainly was. But then the clear text SNI is a gaping privacy hole in TLS, the kind of issue that should keep us awake at night until it is resolved. We need to make sure that we make progress, rather than rehash the old arguments. Maybe we should invest some time and document the various proposals in a draft. I am willing to work on that. Any other volunteers? -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On 05/10/2017 02:12 PM, Christian Huitema wrote: > > On 5/10/2017 12:04 PM, Viktor Dukhovni wrote: >>> On May 10, 2017, at 2:47 PM, Hubert Kario wrote: >>> >>> But in general, I wonder if we didn't approach the SNI from the wrong side >>> - >>> as I said, we may not need to encrypt it, we just make sure that client and >>> server agree on the virtual host the connection is going to. >> They can do that with a name in the clear. If the name is to be hidden >> from passive observers, then you do need encryption so that only the >> client and server, and not the passive observers, can recover the name. >> >> Encryption means key agreement, and requires delaying SNI by a round-trip, >> or having published DH shares in DNS, which of course also needs privacy >> protection for SNI encryption to matter. >> >> I do believe this was discussed at some length previously. > It certainly was. But then the clear text SNI is a gaping privacy hole > in TLS, the kind of issue that should keep us awake at night until it is > resolved. We need to make sure that we make progress, rather than rehash > the old arguments. Maybe we should invest some time and document the > various proposals in a draft. I am willing to work on that. Any other > volunteers? > It seems like there are a number of ways to encrypt the SNI for the *second* (and subsequent) exchange with a given server; I have one that I have some notes on and might try to write up. But do we think that's worth doing, or do we want to also provide protection for the initial contact? It seems like there is a qualitative difference, there... -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote: > Yes, encrypted SNI was discussed and ultimately rejected. > > But do we really have to send the literal value? Don't we need to just make > sure that the client and server agree on the host that the client wants to > connect? > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending > the salt and the resulting hash, making the server calculate the same hash > with each of the virtual host names it supports and comparing with the client > provided value? What makes encrypting SNI nasty is replay attacks. There also was proposal for putting SNI mapping into DNS (which limits the leakage if DNS lookups are private). However, I came up with a way to use that to attack HTTPS (the usual "default vhost" attacks). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alerts
On 11 May 2017 at 01:21, Matt Caswell wrote: > Do we really need all of these alerts? NSS uses these, but in ways that I don't really understand. I think that this is part of the general issue that TLS does and doesn't really include requirements about how to handle the certificate chain. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
The SNI extension is optional, so you don't have to send the literal value. Indeed quite some number of apps do not send it. Browsers currently can't know if the SNI is required by the origin servers and usually send this, but there could be some signal to not send it. One example could be a HTTP header to tell the browser that SNI should be send and if it isn't present then no SNI is send. Unfortunately this would break current sites but still it can be done the other way around e.g. send a header to not send SNI. Regards, Roland Am 10.05.2017 um 19:28 schrieb Hubert Kario: Yes, encrypted SNI was discussed and ultimately rejected. But do we really have to send the literal value? Don't we need to just make sure that the client and server agree on the host that the client wants to connect? Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending the salt and the resulting hash, making the server calculate the same hash with each of the virtual host names it supports and comparing with the client provided value? (apologies if that was already proposed and rejected) ___ 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] "Encrypted" SNI
On 5/10/2017 2:40 PM, Roland Zink wrote: > The SNI extension is optional, so you don't have to send the literal > value. Indeed quite some number of apps do not send it. Browsers > currently can't know if the SNI is required by the origin servers and > usually send this, but there could be some signal to not send it. One > example could be a HTTP header to tell the browser that SNI should be > send and if it isn't present then no SNI is send. Unfortunately this > would break current sites but still it can be done the other way > around e.g. send a header to not send SNI. Yes. But this is only possible when each service has a separate IP address. The privacy gain occurs precisely when several services share the same address, but that's exactly when the SNI is required. If the SNI was somehow encrypted, adversaries would not be able to use it to find which service the user is connecting to. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
Not necessarily as you may for example use the path part of a URL to distinguish between services. Roland Am 10.05.2017 um 23:50 schrieb Christian Huitema: On 5/10/2017 2:40 PM, Roland Zink wrote: The SNI extension is optional, so you don't have to send the literal value. Indeed quite some number of apps do not send it. Browsers currently can't know if the SNI is required by the origin servers and usually send this, but there could be some signal to not send it. One example could be a HTTP header to tell the browser that SNI should be send and if it isn't present then no SNI is send. Unfortunately this would break current sites but still it can be done the other way around e.g. send a header to not send SNI. Yes. But this is only possible when each service has a separate IP address. The privacy gain occurs precisely when several services share the same address, but that's exactly when the SNI is required. If the SNI was somehow encrypted, adversaries would not be able to use it to find which service the user is connecting to. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: > It certainly was. But then the clear text SNI is a gaping privacy hole > in TLS, the kind of issue that should keep us awake at night until it is > resolved. We need to make sure that we make progress, rather than rehash > the old arguments. Maybe we should invest some time and document the > various proposals in a draft. I am willing to work on that. Any other > volunteers? I agree with Christian's assessment of the problem, and i'd be interested in collaborating on such a draft. The DNS folks are making strides to protect name information (the other main place where this kind of data is leaking). TLS needs to keep up. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The case for a single stream of data
As Ilari says, there's a lot of stuff in here. I'll put some thoughts here at the top, and more inline. First off, it seems somewhat self-evident that if we guarantee 0-RTT non-replay, then of course it makes sense to just concatenate the streams. That is, if 0-RTT data is not replayable, there's not much special about it to merit separating it off from normal application data. This isn't quite exactly true because of the DKG attack, but it may be close enough to not matter. However, I'm still not convinced that requiring strong 0-RTT non-replay is feasible/the right thing to do. So, I do not consider the question of single stream vs. block-of-early-data + 1-RTT stream to be settled. On 05/05/2017 11:28 AM, Colm MacCárthaigh wrote: > > I wanted to start a separate thread on this, just to make some small > aspects of replay mitigating clear, because I'd like to make a case > for TLS providing a single-stream, which is what people seem to be > doing anyway. > > Let's look at the DKG attack. There are two forms of the attack, one > is as follows: > > "Client sends a request with a 0-RTT section. The attacker lets the > server receive it, but suppresses the server responses, so the client > downgrades and retries as a 1-RTT request over a new connection. > Repeating the request". > Does the client always downgrade? We don't require it to do so, in TLS 1.3, though of course browsers would. > In this case, server-side signaling such as the X-header trick doesn't > work at all. But thankfully this attack is equivalent to an ordinary > socket interference attack. E.g. if an attacker today suppressed a > server response to a HTTP request, then the client will do its retry > logic. It's the same, and I think everything is compatible with > today's behavior. > > Next is the more interesting form of the attack: > > "Client sends a request with a 0-RTT section. For some reason the > server can't reach the strike register or single use cache, and falls > back to 1-RTT. Server accepts the request over 1-RTT. Then a short > time later, the attacker replays the original 0-RTT section." > > In this case, server side signaling to the application (such as the > neat X- header trick) also doesn't work, and is not backwards > compatible or secure by default. It doesn't work because the server > application can't be made idempotent from "outside" the application, > so any signaling is insufficient, and is equivalent to the > Exactly-Once message delivery problem in distributed systems. Since a > request might be retried as in case 1, it needs an application-level > idempotency key, or a delay-and-retry strategy (but replay will break > this). There's some detail on all this in the review. End result is > that a server-side application that was never designed to reach > duplicates may suddenly be getting exactly one duplicate (that's all > the attack allows, if servers reject duplicate 0-RTT). > I feel like many applications that use delay-and-retry will see this and conclude that they should just not attempt to use 0-RTT. > What is actually needed here, I think, is client-side signaling. > Careful clients need to be made aware of the original 0-RTT failure. > > So for example, an SDK that writes to an eventually consistent data > store may treat any 0-RTT failure as a hard failure, and *not* proceed > to sending the request over 1-RTT. Instead it Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT; the application can decide it's willing to take the risk or use some other strategy. But I'm not convinced that the TLS stack needs to decide on its own, without application input. > might wait its retry period, do a poll, and only then retry the > request. If the TLS implementation signals the original 0-RTT failure > to the client, as if it were a connection error, everything is > backwards compatible again. Well mostly; to be properly defensive, the > client's retry time or polling interval needs to be greater than the > potential replay window, because only then can it reason about whether > the original request succeeded or not. If there is a strict maximum > replay window, then this behavior is enforceable in a TLS > implementation: by delaying the original failure notification to the > client application by that amount. > And if there is not a strict replay window defined in the spec, then the client must have some way of knowing what window the server is using, etc., etc.. When I added the 10-second guidance that's currently in there, I explicitly wanted something concrete, but was not willing to claim that I knew enough about all possible ways in which TLS can be deployed to make a normative requirement for all users of the protocol. I don't think that's changed; setting a fixed global limit seems to be asking for trouble. I suppose if we really needed to we could stick it in a NST extension, but I don't think we really need to. > Of course browsers won't do this, and that's ok. Brow
Re: [TLS] The case for a single stream of data
On Wed, May 10, 2017 at 10:00 PM, Benjamin Kaduk wrote: > > However, I'm still not convinced that requiring strong 0-RTT non-replay is > feasible/the right thing to do. > [ I've cut a lot for brevity, but hopefully what I've replied with can address this, and the rest ] The case for requiring servers, and especially middle-boxes to provide strong 0-RTT non-replay is really the resource exhaustion, throttle exhaustion and cache timing attacks. I think that's where the really dangerous bugs are, the ones that will be exploited - maybe even inadvertently - and that are a show-stopper for the stateless mitigation. It just doesn't work. Thankfully it's within our capabilities to fix this and there's nothing logically impossible about providing non-replay for the 0-RTT sections. > On 05/05/2017 11:28 AM, Colm MacCárthaigh wrote: > > "Client sends a request with a 0-RTT section. The attacker lets the server > receive it, but suppresses the server responses, so the client downgrades > and retries as a 1-RTT request over a new connection. Repeating the > request". > > Does the client always downgrade? We don't require it to do so, in TLS > 1.3, though of course browsers would. > The current draft says that clients should only use tickets once, if they do that, then the repeat attempt (even if it's still 0-RTT, with a different ticket) is un-correlatable. I feel like many applications that use delay-and-retry will see this and > conclude that they should just not attempt to use 0-RTT. > Per the section of the original review about violation of layers and separation of actors; this breaks the well-established relationship between the layers. It's predictable that a site-administrator will enable 0-RTT without any appreciation for the application-level impact. Vendors are already providing 0-RTT in backwards compatible ways. What is actually needed here, I think, is client-side signaling. Careful > clients need to be made aware of the original 0-RTT failure. > > So for example, an SDK that writes to an eventually consistent data store > may treat any 0-RTT failure as a hard failure, and *not* proceed to sending > the request over 1-RTT. Instead it > > > Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT; the > application can decide it's willing to take the risk or use some other > strategy. But I'm not convinced that the TLS stack needs to decide on its > own, without application input. > I'm just describing the only backwards compatible safe-by-default scheme I can concoct, it's definitely kludgey and awkward. For this thread, my main take-away from it is that separating streams doesn't actually help the application; instead, it's a timing thing. > Does a careful client really need the TLS stack to signal connection > error? Surely the TLS stack will provide a mechanism to inquire as to the > connection state, and whether 0-RTT was rejected. The application could > implement its own delay. > Yep, absolutely; but it'd be client-side signaling, and it's not backwards-compatible or safe-by-default to rely on. > And I read what you wrote in the github issue about how saying "don't use > 0-RTT" is not practical, but I don't believe that it is universally true. > Some (careful) applications will rightly consider the tradeoffs and decide > to not use it. On the web ... there are different forces at play, and it > may well take a (security bug) name and website to cause webapp creators > and framework authors to take proper notice. But I am having a hard time > squaring your point about careful clients with the point about > non-practicality. If there are careful clients, they will heed warnings; > if just using warnings is not practical, then what are the careful clients > doing? > I actually share the optimism here. I think it's workable for careful clients, and I wouldn't hold 0-RTT hostage to the DKG corner case. I think we should ship it. All I'm trying to get at is that separate streams are needless complexity, and they seem to be getting ignored by implementors anyway. Right now there's a very weird take in the draft: let the server figure it out by marking the data as replay-able. Well actually that doesn't work; on the server side, the sections can't always be correlated, and even if they were an application would still need its own anti-retry strategy. It's well-meaning; but doesn't work. We should take it out. Here's an example. Client has two tickets: AA and BB. T1. Client makes 0-RTT request for /foo/ with ticket AA. Servers receives the request and marks as replayable-data, maybe uses AA to derive a convenient idempotency/anti-replay key (like the X- header trick). T2. Client was blocked, Tries again, doesn't re-use the ticket, per the draft. So repeats with 0-RTT again, with ticket BB. Same as before, except now the key is derived from BB. T3. Client tries again, this time over 1RTT. Per the draft, there's *no* signaling of repayable data. What on earth is a serv
