Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension
-- >> *From:* TLS on behalf of Lucas Pardue < >> lucaspardue.2...@gmail.com> >> *Sent:* Tuesday, September 26, 2023 9:48 PM >> *To:* Martin Thomson >> *Cc:* Mike Bishop ; HTTP Working Group < >> ietf-http...@w3.org>; TLS List ; Hewitt, Rory > 40akamai@dmarc.ietf.org> >> *Subject:* Re: [TLS] New Internet Draft: The qpack_static_table_version >> TLS extension >> >> Hi Rory, >> >> I echo Watson and Martin, lets discuss this in the HTTP WG. >> >> As for a very brief technical response. In general I'm supportive of the >> idea of more agility of the static table but I think my motivations would >> be different than the ones behind this proposal. For me, I'd like more >> domain-specific tables to be defined, and to have the possibility of >> asymmetric tables; but lets stick that on the side for now. >> >> The QPACK static table description states "The order of the entries is >> optimized to encode the most common header fields with the smallest number >> of bytes.". How does the proposed append-only table gel with this? I.e. >> each year, the new most common fields are added to the end? At what point >> would it make sense to wipe out the cruft and define a newer table >> altogether? >> >> I think what might be needed is a good amount of datamodelling and >> simulation that is sufficient to decide when there is activation energy to >> make changes. Perhaps the proposal is a compromise to make it low effort >> enough for implementations to update, that they don't need tremendous >> amounts of overwhelming evidence to keep up. IIRC historically the effort >> to sample the Internet and propose a table has been quite high, and there >> have been some criticisms about the outputs. Given the HTTP WG has >> struggled with this aspect, I think it is decidedly impractical to make >> IANA or a designated expert solely responsible for deciding the QPACK >> entries. This is something that has to run through a consensus approach >> IMO, especially as lower entries are more valuable and couldn't ever be >> reclaimed. >> >> I think the largest activation energy would be to convince endpoints to >> implement the negotiation mechanism because it is pushing it into the TLS >> layer and that crosses implementation boundaries. Watson asks why not >> SETTINGS. One answer is that it requires clients to have to wait for the >> server's settings, which adds a delay that many clients don't already >> apply. Trading off latency for a few bytes doesn't sound like a good >> tradeoff. Indeed, this is why we optimised the static table for the >> clien'ts first flight before it knows if the server supports dynamic QPACK >> or not. Putting a client's static QPACK preference in a Client Hello is a >> fingerprinting vector, so that is a concern. Perhaps a middleground is to >> use a SETTING but then rope in the old ALPS proprosal [1] so that the >> client learns the server's view as early as required, and the client sends >> its view in SETTINGS after protection is established. >> >> Changing track a bit, I don't understand why your proposal requires the >> client and server to agree on the extension value. Its a declaration of >> what the endpoint can support and I don't think there is any issue in e.g. >> the client being willing to receive references to entries greater than 99 >> and the server refusing to. Encoding asymmetry is already part of QPACK DNA. >> >> Cheers, >> Lucas >> >> [1] - https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps >> >> >> >> >> >> On Wed, Sep 27, 2023 at 1:40 AM Martin Thomson wrote: >> >> On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote: >> > Apologies if I should respond directly to the mailing list - my old W3C >> > profile has disappeared and I'm trying to get it back... >> >> Just on this point. Watson added the HTTP working group, which I think >> is the right thing to do here. The maintenance of HTTP/3 now formally >> belongs in that group. The work of defining a TLS extension for that >> purpose would occur there (if indeed a TLS extension is the right choice, >> as Watson asks). >> >> As for the W3C involvement, the HTTP working group is an IETF activity >> that - for historical reasons - uses a W3C-hosted mailing list. You don't >> need to be a W3C member to sign up for that list. The process is just a >> little different than for other IETF lists. See >> https://lists.w3.org/Archives/Public/ietf-http-wg/ for details. >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Packet number encryption negotiation
2023年2月14日(火) 14:31 Christian Huitema : > > > On 2/13/2023 7:57 PM, Viktor Dukhovni wrote: > > On Tue, Feb 14, 2023 at 04:22:48PM +1300, Marten Seemann wrote: > > > >> It hides certain bits of the header, as well as the packet number, > >> from an on-path observer. This is crucial to prevent middleboxes from > >> being "helpful" and acting upon (observed) gaps in packet numbers. As > >> such, it's hard to define what a reasonable tradeoff would be. Giving > >> up on an anti-ossification measure always seems fine at first, until > >> at some point it isn't any more. > > > > If the proposed feature is negotiated via a default-off extension, and > > used in high-speed internal datacentre networks, then its use is at the > > internal discretion of the datacentre network designers. Presumably, in > > such networks middleboxes of the sort you mention are a no-go just on > > performance grounds. > > > > Yes, especially if not on by default, the feature is liable to run into > > barriers on networks with random middlebox crud. Is sufficient reason > > to preclude well-motivated negotiated use elsewhere? > > Cue the "visibility" discussion... The usual argument against lowering > protections "in a controlled environment" is that, in practice, once an > extension is defined, there could be massive pressure to use it outside > of the purported environment. > > Personally, if I was engaged in a hardware acceleration project, I would > try hard to make the hardware work on an unchanged spec. I don't think > that's impossible, once you look at the spec closely. > +1 to this. I would hope we could choose NICs that support crypto offloading of QUIC traffic unchanged, so that we could offload encryption of packets that we ship over the Internet, rather than just intra-datacenter traffic. Many protocols, if not all, have their own complexity when you offload crypto. To my knowledge, when retransmitting a TLS-encrypted TCP packet, you have to reencrypted bytes then throw them away just to calculate the AEAD tag, because the byte boundaries of TCP packets do not match that of TLS records. In that respect, QUIC and DTLS/1.3 are simpler than TLS over TCP. I get that any complexity is a cost, but I wonder how costly it would be to actually support crypto offload with PNE compared to without. Is that so different that it stops people from buying NICs with crypto-offload support? > RFC 9001 says that the header encryption material applied to the first > byte of the header and to the packet number is obtained by encrypting a > 16 byte sample of the encrypted payload. From RFC 9001: "The sample of > ciphertext is taken starting from an offset of 4 bytes after the start > of the Packet Number field." To obtain these 16 bytes, the encryption > hardware has to obtain at most the first 32 bytes of the encrypted > payload before applying the header protection, and forwarding the header > and these 32 bytes. Yes, this is harder than not doing it at all. And > yes, that requires maybe 40 or 50 bytes of latency. But it could > certainly be done. > > -- Christian Huitema > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-davidben-tls-batch-signing
+1 for adoption. 2019年11月21日(木) 18:49 Salz, Rich : > I am against the working group NOT adopting this. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Two Multi-CDN proposals
osal, but I think this is an open issue >> > beyond ESNI or these PRs. >> > >> > Maybe someone better-steeped in DNS/DNSsec can help us figure out how all >> > that should work, and I agree with you that there are definitely bumps >> > here we need to iron out – maybe those are just questions to answer, or >> > maybe changes to the structure of the record are warranted. >> > >> > However, these PRs are primarily about what information should be in these >> > records and how clients make use of it. I disagree with you that we have >> > to resolve both questions at the same time. Let’s agree on content first, >> > and spent some time separately with DNS folks to see whether the content >> > can be more pleasantly arranged. >> >> Thanks all for the discussion so far! Focusing strictly on the content >> of the records and not the formatting, as Mike suggests, we >> essentially have the following: >> >> - #137 gives clients a way to detect A/+ESNI mismatch and recover, >> at the cost of another sequential DNS query for ESNI. In this change, >> A/ records still control where traffic goes. >> - #136 never requires clients to send a second DNS query for ESNI >> since clients ignore the A/ results. In this change, ESNI records >> dictate routing. >> >> With #137, clients willing to send a second DNS query will get ESNI >> for all supporting providers. Clients unwilling to send a second DNS >> query will only get ESNI for those providers which ensure that their >> A/ and ESNI records very rarely mismatch. With #136, clients only >> get ESNI for those providers capable of building ESNI records with >> correct addresses. In theory, these providers should be the same ones >> that could ensure A/ and ESNI record matching. >> >> Given this, the discussion seems to hinge on the following question: >> Are operators comfortable with the risks of letting ESNI records >> control routing. If so, #136 is probably a better design for said >> operators. If not, then #137 is probably required. >> >> >> >> Thanks for the summary, Chris. >> >> Speaking for Cloudflare, we prefer the method described in #136 and would be >> willing to implement ESNI records this way. >> >> >> >> I have sympathy for organizations with a preference for #137 for >> debuggability reasons, but I would rather avoid situations in which the >> client needs to do an additional DNS query if avoidable. >> >> >> >> I would support the option to include either extension based on operator >> preference. >> >> >> >> This more or less aligns with my views. >> >> >> >> From my perspective, we know that #136 is safe, although it may be >> inconvenient for some operators, and it's not clear to me that #137 can be >> made to work without frequently incurring another serialized DNS query. If >> we had some evidence to the contrary, I would be somewhat more favorable to >> #137, though I would probably still prefer #136 for reasons of simplicity, >> especially as we can always add #137 later if it proves viable.. >> >> >> >> -Ekr >> >> >> >> >> >> >> Note that this does not mean we must choose between #136 and #137 >> right now. We can do both (after possibly simplifying #137!), use >> them, and see what works best in practice. >> >> Anyway, I hope this summary accurately captures the differences and >> possible tradeoffs. >> >> Best, >> Chris >> >> ___ >> 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 -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Two Multi-CDN proposals
2019年3月2日(土) 1:57 Christopher Wood : > > On Wed, Feb 27, 2019 at 11:34 PM Kazuho Oku wrote: > > > > Hi Chris, > > > > Thank you for writing down the PRs describing possible designs that we > > might adopt. I think it helps a lot in understanding the details and > > making accurate comparisons. > > > > My comments inline. > > > > 2019年2月27日(水) 8:19 Christopher Wood : > > > > > > Hi folks, > > > > > > Below are two PRs that seek to address the multi-CDN issue discussed > > > on this list and in meetings: > > > > > >1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 > > >2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 > > > > > > #136 implements the combined or stapled record approach discussed > > > several times, most recently in [1]. It includes these via an ESNIKeys > > > extension. > > > > Reading the PR, I think that there is a mild privacy concern. The > > issue with the unified record proposal is that it incentivizes the > > operators to create more ESNI records possibly using different keys, > > which is against the design principle of ESNI: provide anonymity set > > by using the least number of keys. > > > > Retaining address resolution unbundled with ESNI incentivizes the > > operator to use less number of keys; for example they might just use > > one key at a time. That would be a nice property to have, especially > > in terms of transparency. It would help third parties verify that an > > operator is actually providing an anonymity set (rather than just > > pretending to use ESNI). > > I don't quite agree with this. Operators can already use different > keys across records if they so choose. That said, given the concern, > we could add advisory text suggesting that operators use as few ESNI > keys as possible to cover addresses. Having a guidance sounds sufficient to me. > > > Also, I would like to point out that it is only when one key is used > > by each of the provider at a given time that it would be possible to > > use ESNI from a network that blocks DoH or DoT; a user can write the > > IP addresses of services he/she wants to access in the hosts file, and > > supply the ESNI key to the client he/she uses. Such a hack becomes > > difficult under the unified approach, where operators could synthesize > > different keys based on various conditions. > > Good point! > > > > > At the least, if we are to adopt #136, I think we should change the > > definition of record digest included in the ClientHello extension so > > that it does not cover the "address_set" extension of the ESNI record. > > Otherwise, we would be exposing to the wire the fingerprint of the set > > of IP addresses contained in the DNS response the client received > > through a secure channel, whereas in the split record approach you > > only leak the ESNI key being used and the IP address the client has > > chosen. > > I'm not sure this is an issue. Clients that use HappyEyeballs will > already reveal the set of addresses by attempting to connect to them. Using happy eyeballs does not always mean that the clients are exposing all the addresses in the address_set. IIUC, a client does not eyeball between multiple addresses belonging to the same address family. > > As much as I like the idea of bundling IP addresses and ESNI key, I am > > concerned if the requirement to bundle different types of records is a > > requirement specific to ESNI. If not, I think we should (in the long > > term) try to create a generic solution, while in the short time we > > could rely on a more limited mechanism as proposed in #137. > > In my view, since these are both extensions, they can both proceed in > parallel. If some operators can support #136, and can do so without > creating many ESNI keys, then I think it's worth including. Operators > for which this is not a concern do not need to support the extension, > right? I think the idea of using extensions is a nice approach to move forward. I won't oppose to having an "option" to change the way the address is being resolved, as long as it does not hinder the standardization of the draft without the feature. > > > > #137 builds on this design with a mechanism that lets > > > clients detect and recover from A/ and ESNI mismatch (if desired). > > > It is certainly more complex in several respects. A third variant, > > > which is not (yet) in PR form, is a simplification of #137 wherein > > > ESNIKeys addresses are only used as filters, instead of filters *or* > > > complete addresses. > > > > I think using IP address blocks to limit the validity of the ESNI key > > is a fine approach. I do not oppose to having a name-based filter if > > it's impossible for certain operators to apply the IP address-based > > filtering approach. > > Indeed -- that's the only reason the name exists. > > Best, > Chris -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Two Multi-CDN proposals
Hi Chris, Thank you for writing down the PRs describing possible designs that we might adopt. I think it helps a lot in understanding the details and making accurate comparisons. My comments inline. 2019年2月27日(水) 8:19 Christopher Wood : > > Hi folks, > > Below are two PRs that seek to address the multi-CDN issue discussed > on this list and in meetings: > >1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 >2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 > > #136 implements the combined or stapled record approach discussed > several times, most recently in [1]. It includes these via an ESNIKeys > extension. Reading the PR, I think that there is a mild privacy concern. The issue with the unified record proposal is that it incentivizes the operators to create more ESNI records possibly using different keys, which is against the design principle of ESNI: provide anonymity set by using the least number of keys. Retaining address resolution unbundled with ESNI incentivizes the operator to use less number of keys; for example they might just use one key at a time. That would be a nice property to have, especially in terms of transparency. It would help third parties verify that an operator is actually providing an anonymity set (rather than just pretending to use ESNI). Also, I would like to point out that it is only when one key is used by each of the provider at a given time that it would be possible to use ESNI from a network that blocks DoH or DoT; a user can write the IP addresses of services he/she wants to access in the hosts file, and supply the ESNI key to the client he/she uses. Such a hack becomes difficult under the unified approach, where operators could synthesize different keys based on various conditions. At the least, if we are to adopt #136, I think we should change the definition of record digest included in the ClientHello extension so that it does not cover the "address_set" extension of the ESNI record. Otherwise, we would be exposing to the wire the fingerprint of the set of IP addresses contained in the DNS response the client received through a secure channel, whereas in the split record approach you only leak the ESNI key being used and the IP address the client has chosen. As much as I like the idea of bundling IP addresses and ESNI key, I am concerned if the requirement to bundle different types of records is a requirement specific to ESNI. If not, I think we should (in the long term) try to create a generic solution, while in the short time we could rely on a more limited mechanism as proposed in #137. > #137 builds on this design with a mechanism that lets > clients detect and recover from A/ and ESNI mismatch (if desired). > It is certainly more complex in several respects. A third variant, > which is not (yet) in PR form, is a simplification of #137 wherein > ESNIKeys addresses are only used as filters, instead of filters *or* > complete addresses. I think using IP address blocks to limit the validity of the ESNI key is a fine approach. I do not oppose to having a name-based filter if it's impossible for certain operators to apply the IP address-based filtering approach. > We are asking for feedback on these PRs, as we would like to merge one > of them for the next draft version. As #136 is simpler and permits > extensibility, that is the current preference. > > Thanks in advance for your feedback. > > Best, > Chris (no hat, on behalf of the authors) > > [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI robustness and GREASE PRs
Hi David and others involved in the work, Thank you for the PR. 2018年12月18日(火) 8:18 David Benjamin : > > Hi folks, > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd like > the group's thoughts on. The goal is to make ESNI more robust and eliminate a > bunch of deployment risks. The PRs are linked below: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > The first tries to make ESNI more robust. It introduces the notion of a > "public name" which gives the client an authenticated signal to retry with > new keys or without ESNI at all. This mitigates DNS/server mismatches (a > concern on each key rotation), and partial rollouts or rollbacks (a concern > when first enabling it, plus some scenarios with TLS-terminating middleboxes). I think that this is a logical solution, under the premise that we need to the fix issue. It provides an authenticated signal, thereby protecting the server-name from even the active attackers. That makes the SNI exchange as secure as DoH or DoT. DNS lookup and SNI are the two moments that we need to protect the server name, and having secure exchange for the both is IMO the correct path. Also, I actually like the fact that there is a non-negligible amount of overhead in the fallback path, because that would encourage people to deploy ESNI correctly. > > The second recommends clients to send GREASE ESNI extensions when they do not > have cached ESNIKeys available. This better meets the "Do not stick out" > goal. The server behavior in the first PR gives us this for free. I agree that having ESNI extension everywhere is an improvement. We should do this regardless of if we take PR 124. > > Details are in the PRs. > > (The two PRs were originally written up together. I split them in two based > on some feedback, but since they touch the same text, the GREASE PR includes > the robustness PR. If the WG wishes to go with one but not the other, the > text and details can be adjusted accordingly.) > > Thoughts? > > David > > [*] Steven and I wrote the text itself, with input from Adam, Ben, and Brad, > all CC'd. > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DNS-based Encrypted SNI
o AFXR carries only the TTL. Therefore, an out-of-sync authoritative server will continue to respond with the outdated ESNIKeys. The fact makes it harder for server administrators to manage the keys. To summarize, what we want is consistency (stop sending valid ESNIKeys when authoritative servers get out-of-sync) over availability (continue sending ESNIKeys when out-of-sync), which is contrary to what DNS tries to provide. Considering that and also the fact that we might want to distribute ESNIKeys using methods other than DNS, I think it is a good idea to have not_after (and not_before) in the specification. [1] https://github.com/ekr/draft-rescorla-tls-esni/pull/23 [2] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03#section-3.4 > > >> > - Extensions is just there because we're trying to be safe. >> >> Sure, but I hope we consider dropping 'em if there's no need.. >> New RRTYPEs could always be used for extensions (if new RRTYPEs >> are cheap, that is:-) > > > I would not be in favor of this. It's trivial to parse and ignore. > > >> > (thus making the internal structure opaque to DNS). Removing >> > things won't make it much smaller because a big chunk of >> > the data is in the keys. For instance, in my implementation, >> > the object is 70 bytes long and 34 bytes of that is key (X25519) >> > and 8 bytes is cipher suite (each of these has 2 bytes of length). >> >> That's good. But I was more thinking about how friendly this >> would be for the DNS admin folks. One thing I like about TLSA >> and CAA is that (for my use-cases:-) I can just cut'n'paste >> the values into zone files and they'll be good until a CA root >> key or name changes, which is pretty rare and would be widely >> advertised ahead of time. >> >> With RRSIGs and similar, I can also easily inspect values by >> just looking at zonefiles and/or using dig, which is helpful >> for me at least. But I don't have to deal with large zones so >> that kind of inspection may not be of much use to larger >> operators. So, I'd defer to real DNS server folks on whether >> or not being able to directly view the internals of ESNIKeys >> encoding makes any difference. >> >> All that said, I did just suggest adding in the dummy sni >> value:-) So I mostly think if this goes ahead (as I hope it >> does), we spend a bit of time considering the above issues >> before we're done. > > > Sure, that seems reasonable. I think you are getting to something > important here: my philosophy here is that this should be a more > or less opaque blob which you provide to the TLS stack. So I'm > optimizing for what's convenient for that. I can understand that > others might feel differently. > > -Ekr > >> >> Cheers, >> S. >> > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DNS-based Encrypted SNI
2018-07-04 0:55 GMT+09:00 Eric Rescorla : > > > On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters wrote: >> >> On Mon, 2 Jul 2018, Eric Rescorla wrote: >> >>> It is strongly recommended not to use TXT records. Why not use a >>> new >>> RRTYPE? Everything these days knows how to serve unknown record >>> types >>> (see RFC 3597). The only possibly exception is provisioning tools >>> of >>> small players, but this document starts of saying you basically >>> need >>> to be on a bulk hosting provider anyway. They can properly >>> provision. >>> >>> See: >>> >>> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906 >> >> >> [Can we keep the discussion within the IETF and the Note Well please. We >> also don't know what happens in 10 years with these links.] > > > If you look carefully, you'll see that this discussion happened weeks ago. I > was > just pointing you at it because you asked why we did it the way we did. > > With that said,IETF policy does not prohibit having discussions on Github.. > We do it > regularly in TLS and it's the standard policy in QUIC. > > >> >> quoting from that link: >> >> These facts lead to the conclusion that if we choose RRtype as the >> method, there would often be cases where the DNS record of the >> ESNIKey >> and the TLS server would be required to be operated by different >> entities. >> >> That seems to have confused two things with each other. I did not say >> anything about the location of the DNS record, only of the RRTYPE. >> Clearly, with the same location, it would be under control of the same >> entity, so I don't understand why you bring this up as a reason against >> using a dedicated RRTYPE. > > > I'm just quoting Kazuho here, so I'll let him respond to himself. The discussion was about comparing two approaches: a) use a new record type without suffix, b) use TXT record type with suffix. My argument was that we should select b because a has the deployability issue in regard to APEX names. It is true that the deployability issue is a concern related to the non-use of prefix. It is _not_ related to the selection of the record type. OTOH, I think that the reliability issue related to using a new record type exists, as others have pointed out. > > -Ekr > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
Hi, Thank you for your comments. 2017-07-19 7:05 GMT+02:00 Ilari Liusvaara <ilariliusva...@welho.com>: > On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote: >> Hi, >> >> I am happy to see us having discussions on how to protected SNI. I am >> also happy to see that draft-huitema-tls-sni-encryption [1] proposes >> actual methods that we might want to use, and that the I-D discusses >> about various attack vectors that we need to be aware of. >> >> On the other hand, as stated on the mailing list an on the mic, I am >> not super happy with the fact that the proposed methods have a >> negative impact on connection establishment time. >> >> So here goes my straw-man proposal, as an Internet Draft: >> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/. > > At least that method does not obviously vulernable to replay. However, > it has multitude of other problems: > >> In essence, the draft proposes of sending information (e.g., >> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a >> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI. > > There are multiple problems with use of DNS: > > - Individual DNS records can be at most 64kB. > - The whole DNS reply can be at most 64kB. > - In practice, exceeding about 1200 bytes for response starts > causing problems with DNSoDTLS (there is a fallback to DNSoTLS, > but it is not very pleasant). Yes. It is very unlikely that a TLS bootstrap record that contains a signature and a certificate chain will fit into a single packet, hence there would be a performance penalty if DNS over DTLS that fallback to TLS is used. I have had DNS over QUIC in mind when writing the draft, and I might say that the draft (especially the mode that bootstraps the _signed_ signature) is written under the premise that DNS over QUIC will become popular in the future. > - The textual representation starts getting unpleasant way before > that. > - DNS records are defined to have textual and wire formats. Using TLS > notation would be pretty great for latter, but not good for the > former. Generally speaking, for the following two reasons, I prefer having a TLS structure that defines how a bootstrap information should be encoded, and then have a DNS record type that conveys the information. First reason is because the certificate chain and the signature that signs the EC(DH) keys ideally should be validated the same way as we do with the server certificates transmitted within a TLS handshake. It would make sense to just convey certain extensions that affect the behavior of validation (e.g., OCSP stapling extension) as-is, rather than trying to come with corresponding textual representations. Second reason is that we might want to transmit the bootstrap record using something other than DNS. >> Since DNS queries can run in parallel, there would be no negative >> performance impact, as long as DNS responses can be obtained in a >> single RTT. > > Unfortunately, this is not quite true: > > - Packets can get lost, and DNS retransmissions are fairly slow. > - There are lots of horked DNS servers that respond in all sorts of > bad ways (including timing out, or sending utterly bogus error > codes) to unknown RRTypes, especially if the RRType number is > above 255 (but bad servers that do that to any RRType they do > not know about still exist). If DNS over QUIC (or TLS) is used to transfer a signed bootstrap record with a certificate chain, the amount of data that is sent (in sum of DNS query and TLS handshake) will be roughly the same, assuming that Cached Information Extension (RFC7924) is used. Therefore, I believe that the performance will be roughly the same even when taking packet loss into consideration. If UDP-based DNS protocol is used to transfer a signed bootstrap record with a certificate chain, the DNS query needs to fallback to TCP, since the record does not fit into a single packet. That means that it would never be possible to obtain the DNS response in 1 RTT in such case. If UDP-based DNS protocol is used to transfer a bootstrap record without a sign or a certificate chain, then the question will be how high the probability will be in the following two cases: lose more than 1 packet within 2 packets vs. lose more than 1 packet within 4 packets. I agree that amortized performance will be worse for the latter. > (And let's also ignore difficulties in adding new RRTypes, despite > RFC3597 being almost 14 years old, and covering almost everything that > has been added (one needs extra justfication for breaking RFC3597- > complatiblity[1]).) > > > [1] In practicular, following kinds of things break RFC3597: > > - Compressing RRDATA with reference to rest of the DNS message (e.g., >
Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
Hi, Thank you for the response. I was not aware that the penetration rates of minor DNS records were low. I will read the I-D and the mailing list archive. OTOH, I think that the penetration rate being low might not be a killer for the proposal, since in the short term, SNI encryption can be an opportunistic feature, considering the fact that DNS packets will be sent in cleartext anyways. It might be possible to query for the A record and the bootstrap record simultaneously and activate SNI protection only if responses to both queries are obtained. 2017-07-19 6:03 GMT+02:00 Tom Ritter <t...@ritter.vg>: > If I remember correctly, the idea of enabling SNI encryption (and > 0RTT) via DNS had been brought up very early on in the discussion. > draft-nygren-service-bindings was the first (only? major?) concrete > proposal. > > In general, I think the feedback was "DNS gets filtered to only > A/CNAME records so frequently that anything that relies on other DNS > records isn't going to work an appreciable portion of the time". > > I'm disappointed by this also; but as we are also trying to deploy DNS > privacy - mechanisms that rely on an easily surveilled, censored, or > blocked mechanism to enable other sorts of privacy are concerning. > > -tom > > > On 18 July 2017 at 22:42, Kazuho Oku <kazuho...@gmail.com> wrote: >> Hi, >> >> I am happy to see us having discussions on how to protected SNI. I am >> also happy to see that draft-huitema-tls-sni-encryption [1] proposes >> actual methods that we might want to use, and that the I-D discusses >> about various attack vectors that we need to be aware of. >> >> On the other hand, as stated on the mailing list an on the mic, I am >> not super happy with the fact that the proposed methods have a >> negative impact on connection establishment time. >> >> So here goes my straw-man proposal, as an Internet Draft: >> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/. >> >> In essence, the draft proposes of sending information (e.g., >> semi-static (EC)DH key) to bootstrap encryption in ClientHello as a >> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI. >> >> Since DNS queries can run in parallel, there would be no negative >> performance impact, as long as DNS responses can be obtained in a >> single RTT. >> >> The draft mainly discusses about sending a signed bootstrap >> information together with the certificate chain, since doing so is not >> only more secure but opens up other possibilities in the future (such >> as 0-RTT full handshake). However, since transmitting a bootstrap >> record with digital signature and identity is unlikely to fit in a >> single packet (and therefore will have negative performance impact >> until DNS over TLS or QUIC becomes popular), the draft also discusses >> the possibility of sending the EC(DH) key unsigned in the "Things to >> Consider" section. >> >> I would appreciate it if you could give me comments / suggestions on >> the proposed approach. Thank you in advance. >> >> [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ >> >> >> -- Forwarded message -- >> From: <internet-dra...@ietf.org> >> Date: 2017-07-19 5:38 GMT+02:00 >> Subject: New Version Notification for draft-kazuho-protected-sni-00.txt >> To: Kazuho Oku <kazuho...@gmail.com> >> >> >> >> A new version of I-D, draft-kazuho-protected-sni-00.txt >> has been successfully submitted by Kazuho Oku and posted to the >> IETF repository. >> >> Name: draft-kazuho-protected-sni >> Revision: 00 >> Title: TLS Extensions for Protecting SNI >> Document date: 2017-07-19 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/ >> Htmlized: https://tools.ietf.org/html/draft-kazuho-protected-sni-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00 >> >> >> Abstract: >>This memo introduces TLS extensions and a DNS Resource Record Type >>that can be used to protect attackers from obtaining the value of the >>Server Name Indication extension being transmitted over a Transport >>Layer Security (TLS) version 1.3 handshake. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> -- >> Kazuho Oku >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt
Hi, I am happy to see us having discussions on how to protected SNI. I am also happy to see that draft-huitema-tls-sni-encryption [1] proposes actual methods that we might want to use, and that the I-D discusses about various attack vectors that we need to be aware of. On the other hand, as stated on the mailing list an on the mic, I am not super happy with the fact that the proposed methods have a negative impact on connection establishment time. So here goes my straw-man proposal, as an Internet Draft: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/. In essence, the draft proposes of sending information (e.g., semi-static (EC)DH key) to bootstrap encryption in ClientHello as a DNS record. Clients will use the obtained (EC)DH key to encrypt SNI. Since DNS queries can run in parallel, there would be no negative performance impact, as long as DNS responses can be obtained in a single RTT. The draft mainly discusses about sending a signed bootstrap information together with the certificate chain, since doing so is not only more secure but opens up other possibilities in the future (such as 0-RTT full handshake). However, since transmitting a bootstrap record with digital signature and identity is unlikely to fit in a single packet (and therefore will have negative performance impact until DNS over TLS or QUIC becomes popular), the draft also discusses the possibility of sending the EC(DH) key unsigned in the "Things to Consider" section. I would appreciate it if you could give me comments / suggestions on the proposed approach. Thank you in advance. [1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ -- Forwarded message -- From: <internet-dra...@ietf.org> Date: 2017-07-19 5:38 GMT+02:00 Subject: New Version Notification for draft-kazuho-protected-sni-00.txt To: Kazuho Oku <kazuho...@gmail.com> A new version of I-D, draft-kazuho-protected-sni-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-protected-sni Revision: 00 Title: TLS Extensions for Protecting SNI Document date: 2017-07-19 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt Status: https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/ Htmlized: https://tools.ietf.org/html/draft-kazuho-protected-sni-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00 Abstract: This memo introduces TLS extensions and a DNS Resource Record Type that can be used to protect attackers from obtaining the value of the Server Name Indication extension being transmitted over a Transport Layer Security (TLS) version 1.3 handshake. 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. The IETF Secretariat -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt
Thank you for updating the draft. I really appreciate your effort to have the example vectors documented. It will be a great help to the implementers. One minor request: it would be great if you could add examples for the exporters. Bug in a exporter is hard to find unless you have an interop between applications that actually use it (however TLS itself doesn't use it). It wasn't until the QUIC hackathon that we found issues. 2017-07-17 11:28 GMT+02:00 Martin Thomson <martin.thom...@gmail.com>: > I've revised the draft. It now covers -21. > > I had to make a few changes to ensure that the changes to the > resumption secret for tickets was exposed in the draft, you can now > see the resumption secret being split based on the ticket_nonce. > > On 17 July 2017 at 09:18, <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 of the IETF. >> >> Title : Example Handshake Traces for TLS 1.3 >> Author : Martin Thomson >> Filename: draft-ietf-tls-tls13-vectors-02.txt >> Pages : 36 >> Date: 2017-07-17 >> >> Abstract: >>Examples of TLS 1.3 handshakes are shown. Private keys and inputs >>are provided so that these handshakes might be reproduced. >>Intermediate values, including secrets, traffic keys and ivs are >>shown so that implementations might be checked incrementally against >>these values. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-02 >> >> >> 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 -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt
ema-tls-sni-encryption > Revision: 00 > Title:SNI Encryption in TLS Through Tunneling > Document date:2017-06-20 > Group:Individual Submission > Pages:19 > URL: > https://www.ietf.org/internet-drafts/draft-huitema-tls-sni-encryption-00.txt > Status: > https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ > Htmlized: > https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-huitema-tls-sni-encryption-00 > > > Abstract: >This draft describes the general problem of encryption of the Server >Name Identification (SNI) parameter. The proposed solutions hide a >Hidden Service behind a Fronting Service, only disclosing the SNI of >the Fronting Service to external observers. The draft starts by >listing known attacks against SNI encryption, and then presents two >potential solutions that might mitigate these attacks. The first >solution is based on TLS in TLS "quasi tunneling", and the second >solution is based on "combined tickets". These solutions only >require minimal extensions to the TLS protocol. > > > > > 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. > > The IETF Secretariat > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt
Hi Willy, 2017-06-26 17:01 GMT+09:00 Willy Tarreau <w...@1wt.eu>: > Hi Kazuho, > > On Mon, Jun 26, 2017 at 04:03:24PM +0900, Kazuho Oku wrote: >> One question: is the name `early-data` a good choice? >> >> The reason I raise the concern is because what the header suggest is >> if the endpoint has not yet seen a proof (i.e. ClientFinished). The >> name "early-data" might be confusing since it may seem to imply _when_ >> the request has been received rather than the current state of the >> connection. > > You mean that you'd prefer something indicating that there were unsafe > (ie not yet validated) early data in fact, that's it ? Yes. That was my intention. > Willy -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3: HRR vs. resumption
Hi, I recall that we have had discussions about how we should combine HRR and resumption. My feeling is that combining the two is a needless complication. Instead, I believe that when a client attempts to resume a session using psk_dhe_ke, then it should use the named group that was used in the previous handshake (i.e. the handshake the client used for establishing the connection from which it obtained the session ticket). It might be beneficial to state such advise in the specification, and that there is no need for server implementors to take care of resumption in case when sending HRR. Having such a guideline might reduce the chance of us creating a vulnerability. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#812: End Of Early Data as handshake
2016-12-13 10:45 GMT+09:00 Martin Thomson <martin.thom...@gmail.com>: > On 13 December 2016 at 12:43, Nick Harper <nhar...@google.com> wrote: >> Right now, I believe it's legal for a client to send ClientHello, early >> data, and end_of_early_data alert without reading any messages from the >> server. This change would require a client to wait for the ServerHello >> before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > It's legal to send EndOfEarlyData at any time as long as it follows > the (first) ClientHello, My understanding is that such action has been banned recently in https://github.com/tlswg/tls13-spec/pull/806. Picotls has been doing this (and therefore I would need to change the code). But nevertheless I support this change and the changes discussed in this thread, since it would simplify the state transition on the server side. > but you are right in observing that it would > be difficult to send it at a different time than when you are entering > it into the transcript. > > p.s., It's the Server Finished that you have to wait for, not just > ServerHello. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
2016-11-19 7:32 GMT+09:00 Eric Mill <e...@konklone.com>: > It seems like TLS 2 and TLS 2.0 have very little support, so it's really > just deciding between: > > TLS 1.3 > TLS 4 (or maybe 4.0) > > I oppose to going to TLS 4, due to the following reasons: * it might give people false notion that SSL 2.0, 3.0 is superior to TLS 1.0-1.2 * if name the new protocol TLS 1.3, 2.0, or 2, then there would be no confusion once SSL goes away. However, if we name the new version TLS 4, then people would (for upcoming tens of years) continue to ask where TLS 2 and TLS 3. > I'll just amplify Rich's and djb's points by noting that the cost of > switching away from TLS 1.3 really only affects a very small number of > people -- really just the people in and around this WG. > > There is a much, much larger universe of people who will make deployment > and implementation decisions, with varying attention span and degrees of > skill, and I think they're best served with a clean start of an unambiguous > version number. Just because it feels uncomfortable to us doesn't mean it > will feel uncomfortable to the larger technical/enterprise community who > don't really *care* about the versioning scheme, they just need to make > some decisions and move on. > > -- Eric > > On Fri, Nov 18, 2016 at 1:07 PM, D. J. Bernstein <d...@cr.yp.to> wrote: > >> The largest number of users have the least amount of information, and >> they see version numbers as part of various user interfaces. It's clear >> how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but >> 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported). >> >> We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type >> of disaster happens to only 1% of site administrators, it strikes me as >> more important for security than any of the arguments that have been >> given for "TLS 1.3". So I would prefer "TLS 4". >> >> Yes, sure, we can try to educate people that TLS>SSL (but then we're >> fighting against tons of TLS=SSL messaging), or educate them to use >> server-testing tools (so that they can fix the problem afterwards---but >> I wonder whether anyone has analyzed the damage caused by running SSLv3 >> for a little while before switching the same keys to a newer protocol), >> and hope that this education fights against 3>1.3 more effectively than >> it fought against 3>1.2. But it's better to switch to a less error-prone >> interface that doesn't require additional education in the first place. >> >> ---Dan >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Verifying the second HelloRequest in TLS 1.3
Hi, In section 4.1.2, the latest draft (18) states that a ClientHello sent in response to a HelloRetryRequest must be identical to the first one except for addition, modification, and removal of the designated extensions. To be precise, the draft states: In that case, the client MUST send the same ClientHello (without modification) except: - If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. - Removing the "early_data" extension (Section 4.2.8) if one was present. Early data is not permitted after HelloRetryRequest. - Including a "cookie" extension if one was provided in the HelloRetryRequest. Does this mean that the ClientHello must be at the octet-level be equivalent (with the exception for the positions at which the necessary extensions are inserted)? Or does this mean that a semantically equivalent ClientHello must be accepted? If this is the case, it would mean that a client is allowed to exchange the order of the extensions within ClientHello. There could be other ways to construct an semantically identical ClientHello that looks different at byte level. I think the latest draft can be interpreted in either way (please correct me if I am wrong), and would like to learn what the answer would be. Thank you in advance. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13 posted
2016-10-27 14:30 GMT+09:00 Eric Rescorla <e...@rtfm.com>: > > > On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku <kazuho...@gmail.com> wrote: >> >> Hi, >> >> Thank you for posting draft-18, and thank you for the simplification of >> RMS. >> >> I have finished implementing resumption and early-data in picotls. The >> effort started just before draft-17 was published, so it would be fair >> to say that my effort is solely based on the up-to-date specification. >> >> I am happy to report that all I have found is one minor issue. >> >> The issue I saw is discordance between PSKIdentity.identity and >> NewSessionTicket.ticket. >> >> In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH >> NewSessionTicket.ticket is <1..2^16-1>. >> >> Is there any reason to only allow a zero-length identity for the former? >> >> My understanding is that when resuming a session, the value of >> NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it >> seems more natural if the permitted range of the two arrays were >> equal. >> >> Please forgive me for the fuss if the difference is intentional. > > > Well, you could have an external PSK which I suppose might be zero length. > > But I also wouldn't argue if we required this to be nonzero length. Thank you for the clarification. Yes, having a zero-length external PSK makes sense. And for the same reason, I would argue that having a zero-length session identifier makes sense as well. For a client-server pair that only talk to the other, a zero-length session identifier would work well. So if we are going to align the ranges of the two arrays, it might make more sense to allow zero-length for both of them, instead of disallowing it. Please forgive me for the nit-pick. > -Ekr > >> >> 2016-10-26 14:43 GMT+09:00 Eric Rescorla <e...@rtfm.com>: >> > Folks, >> > >> > I have just posted draft-ietf-tls-tls13-18. >> > >> > The only wire format change from -17 is that I removed the extra key >> > derivation stage computing resumption_psk from RMS. This was a >> > holdover from when we also had a resumption context. Now PSK for >> > connection N+1 = RMS from connection N. Thanks to Kazuho for >> > suggesting this simplification. >> > >> > This draft also makes a number of minor editorial changes that >> > should make for easier reading. >> > >> > The two remaining open technical issues I am aware of are both >> > requirements issues: >> > >> > 1. Can you resume with a different SNI than the one that the >> >connection was initiated with [current answer is "no"]? >> > >> > 2. Do you need an application profile to do post-handshake >> >client auth [current answer is "no"]? >> > >> > There has been a bunch of discussion of these on the list but no >> > consensus declarations from the chairs. These are easy to change >> > in the draft once the chairs make the call. >> > >> > As always, comments welcome. >> > >> > -Ekr >> > >> > P.S. NSS will be skipping draft-17 and going right to -18. This >> > should happen before Seoul. >> > >> > >> > ___ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> >> -- >> Kazuho Oku > > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls-13-17 posted
2016-10-21 18:33 GMT+09:00 Ilari Liusvaara <ilariliusva...@welho.com>: > On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote: >> Folks, >> >> I have just uploaded draft-ietf-tls-tls13-17. > > Updated my own implementation from -16 to -17 (TODO: Add to > implementations page, it isn't any of the ones listed). > > And since that implementation supports RFC7250 (for the server > certificate), here is my interpretation of it: > > The certificate type is sent in extensions of EE certificate, > via the usual server_certificate_type extension (using the server-side > syntax from RFC7250). > > > Okay, the extension is after the certificate it attaches to (which is > just weird), but turns out this wasn't that bad to implement, due to > how the code happened to be laid out (it first sliced the certificate > message to extract the certificates and only afterwards processed > those). > > > > ... Interop tests with picotls failed: > > - Picotls sends extension 13 (signature_algorithms) in ServerHello, > which my implementation does not like[1]. > - Picotls still seems to have the resumption_context mixed into > hashes. I tought that got nuked when switching to "finished > stuffing"? This causes wrong encryption keys to be derived, > causing the handshake to blow up. > Thank you very much for testing, and for reporting the issues you found. Apparently I missed the changes when I made the adjustments for draft-17. I've pushed the fixes on to my git repository (https://github.com/h2o/picotls) fixing the two issues. Hopefully with them, picotls would be able to communicate with your implementation (I think it might be better to go through my code with draft-17 in hand to see if any other discordances exist, but that'll be in the next week). I am also looking forward to seeing your implementation on the Wiki. > > > [1] Wasn't this ripped out in -17? The -17 draft seems to list that > extension as "clear", shouldn't it be "client" as the AFAIK the > server won't send it? > > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR #699: Simplify traffic key expansion
Hi Martin, Thank you for your response. 2016-10-21 8:05 GMT+09:00 Martin Thomson <martin.thom...@gmail.com>: > On 21 October 2016 at 06:52, Kazuho Oku <kazuho...@gmail.com> wrote: >> Is there any need to expand resumption_psk from resumption_secret? >> >> To me, it is unclear why resumption_secret cannot be used directly as >> a psk, since the two values have the same lengths and since the secret >> is only used for deriving the psk. >> >> Maybe is this something we could also simplify? > > draft-17 makes a simplification along the lines you suggested. Note > that this wasn't as easy to get right as you might have imagined for a > bunch of reasons. Observing the differences between draft-16 and 17, I understand that it has become much simpler. In fact, I have decided to skip implementing the draft-16 style NewSessionTicket and go directly to implementing draft-17, since the newer draft seems easier to implement. Thank you for making those adjustments to the draft. That said, the point I am trying to raise is not something that was fixed in draft-17. It's something that has become apparent in draft-17 thanks to the simplifications being introduced. In draft-16, resumption_secret was used for two purposes: generate resumption_psk and resumption_context. So it made sense to derive resumption_psk from resumption_secret. But in draft-17, my understanding is that resumption_context has been abolished. As the result, generation of resumption_psk has been the only use of resumption_secret. That is the reason I thought it might be worthwhile to remove the following formula in section 4.5.1: resumption_psk = HKDF-Expand-Label(resumption_secret, "resumption psk", "", Hash.Length) and use resumption_secret as the psk. Thank you in advance. Please forgive me if I am missing something. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR #699: Simplify traffic key expansion
Hi, While trying to implement NewSessionTicket, I have noticed that resumption_psk is derived from resumption_secret. Is there any need to expand resumption_psk from resumption_secret? To me, it is unclear why resumption_secret cannot be used directly as a psk, since the two values have the same lengths and since the secret is only used for deriving the psk. Maybe is this something we could also simplify? 2016-10-18 5:08 GMT+09:00 Eric Rescorla <e...@rtfm.com>: > Hi folks, > > https://github.com/tlswg/tls13-spec/pull/699/files > > A while back Steven Valdez pointed out that now that we have the PSK binder > change and dual key ladders, each set of traffic keys is generated from a > different > base secret which has a label folded in [0], so we don't need to have the > "phase" parameter in the traffic key calculation in Section 7.3, which > simplifies things > a bit. Due to an oversight, this didn't make it into the PR, but it seems > straightforward. > > Please let me know ASAP if I have missed something here or you otherwise > object. > > -Ekr > > > [0] client_early_traffic_secret, [sender]_handshake_traffic_secret, > [sender]_traffic_secret_N respectively > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls-13-17 posted
Hello, It's great to see draft-17 being published. Thank you all for the effort. Maybe the addition of extensions field to the Certificate message got lost in the changelog? https://github.com/tlswg/tls13-spec/pull/654 My understanding has been that it was a post-16 change and it changes the wire protocol. 2016-10-21 1:32 GMT+09:00 Eric Rescorla <e...@rtfm.com>: > Folks, > > I have just uploaded draft-ietf-tls-tls13-17. > > The major change in this draft is the removal of the 0-RTT Finished > and resumption_context constructs and their replacement with the > psk_binder. This has a number of side effects: > > - Binds in the original transcript into the resumed handshake > whenever resumption-PSK is used. > > - Provides proof of possession of the RMS by the client (subject > to replay issues). I've moved the obfuscated_ticket_age field > out of the early_data_indication so that it now provides the > same limited anti-replay for non-0-RTT PSK. > > - Removes the need for any early handshake encryption. This change, > along with the dual key ladders we introduced in -16, also allowed > us to simplify the traffic key expansion so we don't need explicit > labels for each key (they are already used in Derive-Secret). > > > Other changes included: > - Tweaking the PSK key exchange modes a bit (and removing the > inoperative ability to specify PSK auth modes, while leaving > a hook to do it later). > > - Cleaned up the cipher suite requirements for resumption and 0-RTT. > You can resume/do PSK as long as the PSK KDF matches, but to do 0-RTT > you need the whole cipher suite must match. > > > This revision resolves all the outstanding technical PRs [0] and all but > one of the non-parked technical issues (#144, whether we should remove the > redundant TLSCipherText.opaque_type and TLSCipherText.record_version > fields). We are pursuing measurements to resolve whether this will > be a compat problem but we don't have them yet. > > As usual, comments welcome. We are already working on implementing > -17 in NSS/Firefox and should have it before Seoul. > > -Ekr > > Full Changelog > - Remove the 0-RTT Finished, resumption_context, and replace with a > psk_binder field in the PSK itself (*) > > - Restructure PSK key exchange negotiation modes (*) > > - Add max_early_data_size field to TicketEarlyDataInfo (*) > > - Add a 0-RTT exporter and change the transcript for the regular exporter > (*) > > - Merge TicketExtensions and Extensions registry. Changes > ticket_early_data_info code point (*) > > - Replace Client.key_shares in response to HRR (*) > > - Remove redundant labels for traffic key derivation (*) > > - Harmonize requirements about cipher suite matching: for resumption you > need to match KDF but for 0-RTT you need whole cipher suite. This > allows PSKs to actually negotiate cipher suites. (*) > > - Explicitly allow non-offered extensions in NewSessionTicket > > - Explicitly allow predicting ClientFinished for NST > > - Clarify conditions for allowing 0-RTT with PSK > > > [0] The two remaining outstanding PRs are: > #680: Forbid post-handshake authentication except when permitted by > application profile. This is almost entirely a requirements-level > change, though it would allow clients to send "unexpected_message" > when receiving an unexpected CertificateRequest. > > #612: TLS 1.3 -> TLS 2.0 > This has no change on the wire format. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16
Hi Ilari, Thank you for trying picotls, and thank you very much for notifying me of the issues you found. I have fixed three issues you reported (i.e. SNI decode error, EC group check error, PKCS not included in Signature Algorithms). Regarding the crash, is your implementation available to public so that I could use it for debugging? Thank you in advance. 2016-10-14 5:33 GMT+09:00 Ilari Liusvaara <ilariliusva...@welho.com>: > On Thu, Oct 13, 2016 at 12:18:03PM +0300, Ilari Liusvaara wrote: >> On Thu, Oct 13, 2016 at 03:17:32PM +0900, Kazuho Oku wrote: >> > TLDR: the spec. was clear and easy to implement, but some test vectors >> > and clarification on what constitutes a Handshake Context would have >> > helped. >> > >> > FWIW, please let me share my experience of implementing TLS 1.3. >> > >> > This month, I have written a TLS 1.3 implementation (named picotls, >> > available at https://github.com/h2o/picotls) based on draft 16 from >> > scratch. >> >> Tried interop versus my own implementation (with my implementation >> as client). >> >> Didn't work... I traced the blowup to client_hello_decode_server_name(): >> >> The sent contents of the SNI extension is: >> >> 00 0B 00 00 08 "h2o.test" >> >> Which AFAICT is a server name list of 11 bytes, containing entry of >> type 0 (host_name), with length 8 and name "h2o.test". > > Further testing: > > My implementation vs. picotls: > -- > > Ok, dumped the handshake using wireshark. Wireshark seems to think > the SNI with two lengths is perfectly sane. > > I modified the picotls code to read the extra length. > > Then I hit another issue: eckey_is_on_group seems to be busted: It > presumably should use == instead of !=, since it is presumably > supposed to return 1 if groups match, since it is used to check > if the key is P-256. > > > Couple of bugs in my code later, I could get successful handshake > with my code as client and picotls as server. Yay. > > > picotls vs my implementation: > - > > Trying picotls as client and my code as server first hit the issue that > picotls doesn't send RSA-PKCS-V1.5 as supported, causing my > implementation to fail with no suitable certificate (it requires > algorithms for the chain too, not just the end key). > > After defeating that check, the handshake got further, but something > in server's messages (ServerHello, EncryptedExtensions, Certificate, > CertificateVerify, Finished) made picotls crash (heap corruption as > evidenced by the malloc() error). Haven't debugged that error yet. > > > > -Ilari -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?
Sorry for the fuss, I think I was confused. Now my interpretation of the draft is as follows. A server is expected to send a Certificate message that contains certificates using the signature algorithms specified by the client, with preference and exception rules defined in section 4.2.3 (Signature Algorithms) and 4.4.1.2 (Server Certificate Selection). A server is expected to generate a Certificate Verify message using a method that is in the intersection of the algorithms specified by the client using the Signature Algorithms extension that is _not_ blacklisted to be used for signing CertificateVerify. The blacklisted ones are: rsa_pkcs1_XXX and those use SHA-1 (rsa_pkcs_sha1, dsa_sha1 ecdsa_sha1). note: It seems that dsa_sha1 and ecdsa_sha1 have _RESERVED suffixes in A.3.1.3 even though they are referred to without the suffixes in the document. Is this an editorial issue? I think I got confused by the way section 4.4.2 (Certificate Verify) blacklists the algorithm. To me the following sentences seemed to indicate that PKCS1 and SHA1 needed different treatments. RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms". SHA-1 MUST NOT be used in any signatures in CertificateVerify. All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. But now to me it seems that both PKCS1 and SHA1 are allowed to be used in Certificate message only (to provide support for legacy certificates). Considering that, to me it seems preferable if the draft stated that both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in certificates. Or is there any need to handle PKCS1 and SHA1 differently in protocol implementations? Thank you in advance. 2016-10-14 13:38 GMT+09:00 Kazuho Oku <kazuho...@gmail.com>: > Hi, > > In TLS 1.3, my understanding is that the digest function negotiated > using the Signature Algorithm should be used for generating > CertificateVerify, since the draft states that: > > | Each SignatureScheme value lists a single signature algorithm that > the client is willing to verify. > | (section 4.2.3) > > | The Hash function and the HKDF hash are the cipher suite hash > algorithm. Hash.length is its output length. > | (section 7.1) > > The draft permits fullbacking back to using SHA1 certificates: > > | TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no > valid certificate chain can be produced without it. > | (section 4.2.3) > > However, the draft also states: > > | SHA-1 MUST NOT be used in any signatures in CertificateVerify. All > SHA-1 signature algorithms in this specification are defined solely > for use in legacy certificates, and are not valid for > CertificateVerify signatures. > | (section 4.4.2) > > So my question is, which signature algorithm am I supposed to use for > a rsa_pkcs1_sha1 certificate? I'd assume that the answer is > rsa_pss_sha256, but I could not find any such indication within the > draft. > > -- > Kazuho Oku -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?
Hi, In TLS 1.3, my understanding is that the digest function negotiated using the Signature Algorithm should be used for generating CertificateVerify, since the draft states that: | Each SignatureScheme value lists a single signature algorithm that the client is willing to verify. | (section 4.2.3) | The Hash function and the HKDF hash are the cipher suite hash algorithm. Hash.length is its output length. | (section 7.1) The draft permits fullbacking back to using SHA1 certificates: | TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it. | (section 4.2.3) However, the draft also states: | SHA-1 MUST NOT be used in any signatures in CertificateVerify. All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. | (section 4.4.2) So my question is, which signature algorithm am I supposed to use for a rsa_pkcs1_sha1 certificate? I'd assume that the answer is rsa_pss_sha256, but I could not find any such indication within the draft. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16
Hi Martin, 2016-10-13 16:07 GMT+09:00 Martin Thomson <martin.thom...@gmail.com>: > Thanks Kazuho! > > Experiences like your own are critical at this stage. It is encouraging to > see that there were so few problems. > > As for the key schedule, EKR and I have discussed taking a dump from one of > our many test cases and putting that in a draft, including private keys and > all the intermediate values. It might get a bit long, so we were thinking of > doing a separate companion document. Would that help you? Yes. That would have helped. Especially it would be great if there was an example of generating AEAD key and IV from the handshake messages. The logic (e.g. HKDF-Expand-Label and Derive-Secret defined in section 7.1) and the parameters that the logic takes as input are defined in different sections of the draft. For example, you have to look at section 2 and 7.3 to find out the correct parameters. So I had to concentrate on getting all them together to form an interoperable code. I won't say it was hard, but having a test vector that goes though the process step by step would have helped a lot. > We haven't done anything yet because the draft has been changing quite a > bit, but I believe that the changes are now mostly done. > > I am happy to take ideas on what configurations to trace. The only thing NSS > doesn't support right now is KeyUpdate (coming soon after -17 I hope). > > Did you want to add your implementation to the wiki? > https://github.com/tlswg/tls13-spec/wiki/Implementations and you would be > most welcome to n join the next hackathon in Seoul. Thank you for the offer. I added my implementation to the wiki. > > > On 13 Oct 2016 5:17 PM, "Kazuho Oku" <kazuho...@gmail.com> wrote: >> >> TLDR: the spec. was clear and easy to implement, but some test vectors >> and clarification on what constitutes a Handshake Context would have >> helped. >> >> FWIW, please let me share my experience of implementing TLS 1.3. >> >> This month, I have written a TLS 1.3 implementation (named picotls, >> available at https://github.com/h2o/picotls) based on draft 16 from >> scratch. >> >> This has been my first time to implement TLS. >> >> I wrote my implementation by going through the draft. While writing my >> code, I did not refer to other implementations except for looking into >> OpenSSL to see if there was an optimized path for implementing AES-GCM >> for TLS 1.3 (which turned out to not exist in 1.0.2; it has been >> introduced in OpenSSL 1.1.0). >> >> After my own implementation of server and client started talking to >> each other, I started to test interoperability by using Firefox >> Nightly. >> >> I had to fix five issues before picotls started talking with Firefox, >> which took about half a day of work (some errors are not strictly >> related to TLS). >> >> Commit 479f25f, ddd50b7 fixed errors in AEAD construction. >> Commit 5cb99c5 fixed an error in RSA signing. >> Commit 2d20c86 fixed a mis-optimization in my implementation of >> Derive-Secret. >> Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. >> >> Details of each commit can be found at >> https://github.com/h2o/picotls/commits/master >> >> It was possible to fix the errors by observing the fatal alert sent by >> Firefox and going back to the Internet Draft. But it would have been >> even more easier if the draft included test vectors especially for the >> cryptographic operations. >> >> Aside from the bugs I fixed, it seemed to me that the draft was vague >> on whether if msg_type and length of Handshake should be considered as >> part of the Handshake Context (please forgive me if I missed somewhere >> that mentions it). >> >> In section 4.4, the draft states that, quote: a Handshake Context >> based on the hash of the handshake messages. This text seems to imply >> that msg_type and length should be considered part of the Context, but >> I could not find a formal definition of what a “handshake message” is. >> >> OTOH, other parts of the Draft seem to refer to Handshake Context as a >> list of Handshake bodies. For example, the table in section 4.4 states >> that the Handshake Context for 0-RTT mode is ClientHello. I think this >> could be interpreted that the Context is not expected to include >> msg_type and length, since ClientHello is a structure that is used as >> a message body. >> >> So even though my interpretation (the former of the two) was correct >> in sense that it matched that of Firefox, I needed to check if the >> browser was interpreting the d
[TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16
TLDR: the spec. was clear and easy to implement, but some test vectors and clarification on what constitutes a Handshake Context would have helped. FWIW, please let me share my experience of implementing TLS 1.3. This month, I have written a TLS 1.3 implementation (named picotls, available at https://github.com/h2o/picotls) based on draft 16 from scratch. This has been my first time to implement TLS. I wrote my implementation by going through the draft. While writing my code, I did not refer to other implementations except for looking into OpenSSL to see if there was an optimized path for implementing AES-GCM for TLS 1.3 (which turned out to not exist in 1.0.2; it has been introduced in OpenSSL 1.1.0). After my own implementation of server and client started talking to each other, I started to test interoperability by using Firefox Nightly. I had to fix five issues before picotls started talking with Firefox, which took about half a day of work (some errors are not strictly related to TLS). Commit 479f25f, ddd50b7 fixed errors in AEAD construction. Commit 5cb99c5 fixed an error in RSA signing. Commit 2d20c86 fixed a mis-optimization in my implementation of Derive-Secret. Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. Details of each commit can be found at https://github.com/h2o/picotls/commits/master It was possible to fix the errors by observing the fatal alert sent by Firefox and going back to the Internet Draft. But it would have been even more easier if the draft included test vectors especially for the cryptographic operations. Aside from the bugs I fixed, it seemed to me that the draft was vague on whether if msg_type and length of Handshake should be considered as part of the Handshake Context (please forgive me if I missed somewhere that mentions it). In section 4.4, the draft states that, quote: a Handshake Context based on the hash of the handshake messages. This text seems to imply that msg_type and length should be considered part of the Context, but I could not find a formal definition of what a “handshake message” is. OTOH, other parts of the Draft seem to refer to Handshake Context as a list of Handshake bodies. For example, the table in section 4.4 states that the Handshake Context for 0-RTT mode is ClientHello. I think this could be interpreted that the Context is not expected to include msg_type and length, since ClientHello is a structure that is used as a message body. So even though my interpretation (the former of the two) was correct in sense that it matched that of Firefox, I needed to check if the browser was interpreting the draft in the latter way, while I tried to fix the AEAD error. The other two issues I had are my confusion on why a Handshake Context may contain Certificate and CertificateVerify after ServerFinished (answered by Illari at https://www.ietf.org/mail-archive/web/tls/current/msg21476.html), and a mistake in encoding draft 16 as 0x16 (https://github.com/tlswg/tls13-spec/issues/682). To summarize, the draft was clear enough for a newcomer to implement the specification, but I think some test vectors and clarification on what consists a Handshake Context might help others trying to implement the protocol. Thank you very much for the great draft, and providing answers to my issues. I am looking forward to seeing it formalized. -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] HMAC context of ClientFinished in TLS 1.3
Hi, Thank you very much for the clarification and the advise. I had indeed forgotten to consider the client certificate and its verify message. iPhoneから送信 2016/10/07 19:14、Ilari Liusvaara <ilariliusva...@welho.com> のメッセージ: >> On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote: >> Hi, >> >> Recently I have started writing a TLS 1.3 implementation. While >> working on it, I have noticed the following. >> >> In section 4.4.3, the hash value used for building the HMAC is defined >> as: Hash(Handshake Context + Certificate* + CertificateVerify*). >> >> For ServerFinished, this corresponds to the statement following the >> formula that states, quote: >> >>the HMAC input can generally be implemented by a running hash, >> i.e., just the handshake hash at this point. >> >> since Handshake Context for 1-RTT server is (as defined in section >> 4.4): ClientHello … later of EncryptedExtensions/CertificateRequest. >> >> However, for ClientFinished, the two descriptions do not match, since >> Handshake Context for 1RTT client is: ClientHello … ServerFinished. >> >> If we follow the way it is defined in the formula, then Certificate >> and CertificateVerify needs to be applied to the hash after >> ServerFinished, which is in discordance with the statement that it >> could be implemented using a running hash. > > Nope, it is a running hash: > > The server Finished includes the following messages, in this order: > > - ClientHello > - HelloRetryRequest (if sent) > - Clienthello (another, if HRR was sent) > - ServerHello > - EncryptedExtensions > - CertificateRequest (if sent) > - Certificate (server's) > - CertificateVerify (server's) > > And this exactly corresponds to the send/receive order. > > > The client finished includes, in this order: > > - ClientHello > - HelloRetryRequest (if sent) > - Clienthello (another, if HRR was sent) > - ServerHello > - EncryptedExtensions > - CertificateRequest (if sent) > - Certificate (server's) > - CertificateVerify (server's) > - Finished (server's) > - Certificate (client's, if CR was sent). > - CertificateVerify (client's, if non-empty client cert was sent) > > And this exactly corresponds to the send/receive order. > > > One place to be careful of is client application keys: The hash used > for those is taken immediately after ServerFinished, but the keys are > only commissioned after ClientFinished (whereas server keys have the > hash taken in the same time as those are commissioned in). > > > > -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] HMAC context of ClientFinished in TLS 1.3
Hi, Recently I have started writing a TLS 1.3 implementation. While working on it, I have noticed the following. In section 4.4.3, the hash value used for building the HMAC is defined as: Hash(Handshake Context + Certificate* + CertificateVerify*). For ServerFinished, this corresponds to the statement following the formula that states, quote: the HMAC input can generally be implemented by a running hash, i.e., just the handshake hash at this point. since Handshake Context for 1-RTT server is (as defined in section 4.4): ClientHello … later of EncryptedExtensions/CertificateRequest. However, for ClientFinished, the two descriptions do not match, since Handshake Context for 1RTT client is: ClientHello … ServerFinished. If we follow the way it is defined in the formula, then Certificate and CertificateVerify needs to be applied to the hash after ServerFinished, which is in discordance with the statement that it could be implemented using a running hash. Is this an error in the draft? -- Kazuho Oku ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
