[Edit: deleted "Fixes" line for ]
From , we also talked about IP addresses and such. Do we still want to do that? Whether the client validation is SHOULD or MUST (TBH I kinda prefer MUST, given the implications on private services... if it's a SHOULD, we should talk about why so implementations can make an informed decision), we do also need to say what values are valid for the server.
OK, switched to a MUST. Added IP addresses as well. I'm calling out to for IPv4/IPv6 parsing. I'd like to avoid any ambiguities that might creep in if I were allowed to define the grammar, like allowing octal numbers in an IPv4 address, e.g. != . For hostname parsing, I'm borrowing from so we can parse IDNs.
I think that is a mistake.
Why is that?
I think IP addresses are a mistake because they can introduce parsing ambiguities (as pointed out above), and sometimes those cause problems (URL). Also, SNI is really limited to hostname (as NAME has pointed out before, referencing AGL's post), and having the two mismatch in their capabilities bothers me.
Agreed that the capability mismatch between SNI and ECHConfig.publicname is odd. However, there is already a capability mismatch between ECHConfig.publicname and names allowable on server certificates. At least in theory, the server's certificate might not have a hostname. That being said, I don't have a strong opinion either way. If we do decide to disallow IP addresses, I think we'd still want the client to look for them so it can reject those ECHConfigs that use IP addresses. This is about stopping wacky values from bubbling up to the application.
The client sending the ECH or the server receiving it? Current TLS stacks don't seem to check, on either side. (At least OpenSSL and its major forks)
I was referring to the client, but yeah, scratch that idea. If public_name can only be a hostname, the client should only validate that it looks like a hostname.
I don't think the capability mismatch between SNI and ECHConfig.publicname is a fatal. We can move ECHConfig.publicname up an abstraction level. I think we should do this whether we allow IPs or not. The public name isn't "put this in ClientHelloOuter.servername" but "the name you are trying to connect to in the outer handshake". In particular, this encompasses both ClientHelloOuter.servername and certificate verification. To fill in ClientHelloOuter.servername, you use the rules in RFC6066: servername is the name you are trying to connect to, provided it's a DNS name. Under this model, it is perfectly coherent for "the name you are trying to connect to" to be an IP address, if we want to do that. If we wish to do that then, yeah, we'll need to spell out the syntax here. That syntax clearly does already exist (URLs, etc.), but not in TLS. I don't particular care whether we do it, though. How about this: Right now, IP addresses are implicitly not okay by way of CHOuter.servername = ECHConfig.publicname. So let's not introduce them in this PR and merely iron out the DNS name validation. This PR adds to, but does not We then rework the text to redefine public_name as above. This is a prerequisite to allowing IPs, but I think it's worth doing either way. We decide the IP question (interim?) and with the result. (Sorry, I think some of this confusion is my fault. I filed two related, but separate, discussion points in , which was confusing. My comment in URL was most in reaction to "; that we shouldn't close it out without resolving both points.)
I think I'd mostly be against supporting IP addresses in ECHConfig.publicname. I suspect including an IP address in URL would break some things. The comment below is from OpenSSL's ssl/statem/extensionssrvr.c: / Although the intent was for servername to be extensible, RFC 4366 was not clear about it; and so OpenSSL among other implementations, always and only allows a 'hostname' name types. RFC 6066 corrected the mistake but adding new name types is nevertheless no longer feasible, so act as if no other SNI types can exist, to simplify parsing. Also note that the RFC permits only one SNI value per type, i.e., we can only have a single hostname. / Separately, we could land ourselves with yet more confusion related to the address to which one ought send a ClientHello, (the address in the ECHConfig or in the URL or the A/AAAA of one of the names involved, and which to prefer if some things have DNSSEC etc etc.). Cheers, S.
NAME Right, I think it's unambiguous, whatever we do with IP addresses, they won't go in ClientHelloOuter.servername. Any use of this, if we want it, would be for public name verification, not the servername value. See my comment above with how to think about public_name.
SGTM, folks. Just dropped the parts about IP addresses.
Looks like I was a little overzealous removing the IP address text. We still need to check that publicname is not an IPv4 address because dotted-decimal IPv4 addresses would slip through the cracks of hostname validation. This is bad because a malicious/misconfigured DNS would cause the ECH client to break 's rule on the contents of "servername": (Re-added this IPv4 check in the last commit.)
I would rather make "validate the host name" be a SHOULD and remove all these requirements.
ECH implementations not validating that string risks surprising behavior for a lot of applications, and potentially more attack surface to private services than before. Have you looked at the discussion in issue , in particular: Sadly, the thing that makes that work (logic earlier in the application) doesn't apply here. See URL
Can you explain your concerns in more detail? I think the application should be responsible for validation.
The application should never see the value of ECHConfig.public_name, right?
See , specifically URL and URL Well, there are several things going on here: First, different systems may differently divide the "TLS" part and the "application" part. The spec mostly captures behavior of the overall client system, because that's all we can usefully talk about. (For example, ECH specifies a retry flow that involves making a new connection. At the level of many TLS libraries, including OpenSSL + derivatives, the caller makes connections. So instead the TLS library can expose APIs and document the caller's responsibilities as part of enabling ECH. Other interfaces may be create their own connections and handle this internally.) So whether it's the application or TLS, at the implementation level, isn't a hard deciding factor. Second, with that said, yes, I expect that the majority of TLS application interfaces will treat the ECHConfigList as an opaque blob. That is a good division of responsibilities because the TLS half already needs to process individual ECHConfigs in the ECHConfigList and select one based on its internal capabilities. Having to thread through application-specific DNS validation seems like it'd be complex. (But this is just my view as an implementor. The spec merely describes the overall behavior of the client system. How you choose to layer it is an implementation decision.) Finally, there's the question of whether TLS as a spec should have opinions here or if it should punt to some upper layer spec profile, as we did with 0-RTT. I don't think that's warranted here. RFC6066 already decided what can go in server_name, so TLS already is plenty opinionated on the shape of strings meant to be DNS names. Thus, IMO, the simplest and most practical story is to have TLS handle this, rather than thread it up through all the layers.
I am willing to accept that I am in the rough here.
As noted in URL, I don't think we should be putting IP addresses in .
In the interest of dealing with one problem at a time, this PR no longer attempts to spell out how to recognize IP addresses. Roughly: The client MUST validate as a LDH hostname. The client SHOULD exclude IP address literals, which may come in many strange forms, or else it may send a non-compliant "servername" extension. If we care to make excluding IP addresses a MUST, let's work out the details in another PR. Same goes for if we want to explicitly support IP address literals — we still need to validate them to protect server applications from receiving IP addresses in non-standard notations, e.g. octal.
I think there are a couple things going on here: ECHConfig.publicname, as currently written, is described as what goes in CHOuter.servername. That wasn't right and we should have made it outer reference identity. I believe NAME is going to do a separate PR after this goes through. SNI or reference identity, we need to define what the type of the thing that goes in ECHConfig.publicname and what validation the client does. In particular, without validation, it gives the network more control over what goes into CHOuter.servername than would otherwise be the case. Normally, in a typical HTTPS client, TLS can just assume the hostname has passed whatever checks earlier in the stack (URL parsing, DNS lookup, etc.) and so checks in TLS are not load-bearing. The public name breaks this because the TLS layer is fabricating a hostname on its own. So we should have TLS validate it before running too far with it. This PR addresses (2).
Following up on NAME comment, I was indeed planning on clarifying that ECHConfig.publicname is a reference identity, and planned on renaming this to something other than to match. Basically: may be either a name or IP address, validated according to the rules in this PR, and clients will use that identity when constructing the ClientHello per the normal rules. (If it's a name, put it in "servername," else don't put it in that name.) I think we can probably land this PR as-is. Is everyone else OK with this plan?
It's a nit, but I don't think I've ever seen a use of the term "identity" that didn't eventually cause confusion. I think public_name was better TBH. Sorry if I missed the discussion but: Are one or more IPv4/IPv6 addresses allowed and if so with what syntax? If only 1 is allowed, why? (Syntax still needs a reference.) I don't know how an IP address here ought be handled if it differs from those in the SVCB address hints fields. (Not to mention the origin's A/AAAA records.) Lastly, I forget why we even want an IP address there at all. Thanks, S.
I assumed there's at most one identity in this field, be it a name or address, but NAME can clarify. Also, I think the identity here only pertains to how the client-facing server is authenticated. If a server uses an IP-address certificate for the rejection path then it might specify the single IP address of that certificate. (Clients don't use SVCB hints for this, so they're orthogonal.)
There can be many SANs even if those are IP addresses. So I think you mean that you want exactly one IP address here and if one is here that MUST match one SAN iPaddress from the cert? Personally I don't think that's useful enough to support but maybe I missed why it was really good. TBH, I doubt implementers will notice that orthogonality. And those deploying even less would be my guess. If one is allowed put a single IP address in an ECHConfig and others in SVCB hints then someone needs to say what to do when those aren't the same. S.
True, but I'm just commenting on parity with what's there right now. (ECHConfig.public_name is just one name.) We may change that later if people want it? I don't see a reason to, though. Yeah, that's what I'm thinking. Hmm, yeah, we may be able to clarify this, but given that we don't discuss anything about the SVCB record (beyond the config) currently, it may not be needed.
Currently, this PR explicitly states that the client SHOULD ignore the ECHConfig if its contains an IP address. Unfortunately, what constitutes a textual representation of an IPv4 address is pretty underspecified, so I didn't manage to come up with a foolproof validation algorithm, otherwise I would make it a MUST. If we want to allow IP addresses, let's figure it out in another PR.
So I don't think that we need to worry about IPv6 here. That will never match LDH. The IPv4 thing is unfortunate. I think that the risk is that the public name is passed to a certificate validation library that subsequently treats the name as an IP address (matching against an ipAddress SAN rather than dNSName SAN) when doing fallback process. If there is any potential for confusion about this string (or look-alikes if we consider the octal mess) then it might happen that there is variation in what certificates are considered OK. That leads to a reliance on the certification authorities being careful about issuance for names that look like IP addresses. We don't want that. Either way, I don't like "SHOULD" here. It retains the potential confusion. If one client component is sloppy and doesn't bother other components are then forced to contend with that choice. I think that I've come around to NAME viewpoint on this. It's reasonable to require a domain name for fallback in all cases, even where a server is identified by IP address alone. I think that means prohibiting IPv4 addresses, just to avoid the potential confusion. That is, if the name contains exactly 4 labels that are only digits, then the record is invalid. IPv6 addresses will look after themselves as they aren't valid LDH A-labels. Note: I don't know if there are rules that might allow 172.0.2.2045 to be registered, which is clearly not an IP address. I believe that the main protection we have against valid DNS names appearing to be IPv4 addresses is the gTLD registration rules (from URL Section 2.2.1.3.1 clause 1.2.1 this is currently assured as only a-z is permitted from the ASCII range).
NAME can you drill into this? I must be misunderstanding you (and maybe the problem), but are you suggesting that strings which look like IP addresses might be parsed incorrectly by the thing validating certificates against such look-alike addresses? They also have to be careful about names that aren't actually domain names ("DROP TABLES" or whatever). How is this a substantially new requirement? Prohibiting IP addresses here seems overly restrictive. Given that it doesn't seem challenging to support, and does not, to my knowledge, introduce any new requirements for CAs or certificate validation APIs, I'd like to hear more reasons why we ought to definitely rule them out. And as NAME says, we should hash this out in a separate issue and PR. In the interest of making forward progress, I'm going to merge this PR as-is, and we can discuss more in .
In most cases, I don't anticipate problems: there will be one certificate validator used during fallback and that will make a single determination. IP address lookalikes in that case probably won't be a problem. However, in cases where there are multiple components involved, there might be IP address lookalikes that pass one validator but not another. That might be used to attack clients.
Given how IPv4 literals can get in some applications, I suspect the TLS library classifying and rejecting IPv4 literals in a way that ensures the calling application always interprets it as a DNS name is hopeless. I'm now inclined to say we should: Do and say publicname is exclusively DNS. If anyone adds IP in the future, the expectation will be a separate extension and thus not require any parsing to pick semantics. The exclusively-DNS publicname field is validated according to DNS rules and leave it at that. That at least avoids completely unbounded DNS control on the ClientHello. Concede that we can't reliably exclude IPv4 literals at this layer. Call this out and say that clients MUST NOT validate the string as IP addresses. If your verifier has separate APIs for configuring DNS vs IP names for subjectAltName, feel free to pass the string as a DNS input and move on. If your verifier's API takes a more URL-like hostname, you should use whatever logic you used to distinguish DNS vs. IP and fail the verification if you think the string is an IP. (Effectively that verifier believes "DNS:1.2.3.4" is never valid because it has no way to spell it.) This does mean the DNS can cause ClientHelloOuter to violate the RFC6066 prohibition on IPv4 literals, but since RFC6066 failed to specify what syntax it was prohibiting, the meaning of that rule is somewhat unclear.
In , there's been a lot of discussion around how and whether or not IP addresses should be allowed as a reference identity of the client-facing server. This issue tracks sorting this particular question out. NAME suggested in the case the reference identity is an IP address. (Whether or not this address is in the ECHConfig is separate.) NAME suggested . (Whether or not this allows the outer SNI to be empty is separate.) So there seems to be two questions we need to sort out, in relation to : Should the ECHConfig be allowed to supply IP addresses? And if so, how do client stacks validate them? Should clients be allowed to validate servers using IP addresses as a reference identity? (If yes, then the ClientHelloOuter.SNI must be allowed to be empty/omitted.) I think (2) should be 'yes', given that's currently possible today introduces no new complexity. I think it should be feasible to spell out the requirements to make (1) feasible, so I also think that should be 'yes'. What do others think?
Yes and yes. RFC 8738 using reverse-IP notation, which seems like a halfway-reasonable option. An "empty" public name seems a little more flexible (doesn't require servers to carry certificates for each other's IP addresses), and ought to be easy enough to support on clients.
NAME to clarify this: You're suggesting that if ECHConfig is empty then the client should use the IP address of the client-facing server as the reference identity, right? That seems like a reasonable way around the language we might need to specify what is a valid address in ECHConfig. (If the reference identity is not empty, then it MUST be a name, otherwise it's the IP address, and clients should connect and validate based on that identity accordingly.)
NAME Correct. NAME previously raised a concern that this could complicate client implementations: the TLS stack can no longer make use of a connected socket given solely on the ECHConfig and inner reference identity; it also needs the remote IP in some cases. This is true, but I think the remote IP is essentially always "at hand" so perhaps it can be passed in unconditionally without too much difficulty.
I don't think that's true when the client is using a proxy, depending on how much of DNS is done on the client and how much is done on the proxy. If the client does the SVCB lookup itself but asks the proxy to look up TargetName, as the SVCB draft , the client won't have the remote IP of the client-facing server available. (Are there weird networks that rewrite addresses at the DNS level? That would also break with this idea.)
To try and sharpen NAME point: will the client always have access to the client-facing server IP? I don't see how this won't always be true, since the client connects to something, but maybe I'm misunderstanding the proxy scenario.
NAME is correct about the behavior when using a SOCKS5 or HTTP CONNECT proxy in domain-oriented mode. The proxy performs A/AAAA resolution and TCP connection establishment, and does not provide this information back to the client, so the client doesn't know which server IP it is using. That does suggest that "empty" won't work.
Oh! I see. The proxy is the one establishing the transport connection.
There's probably at least three modes here, if not more: Proxy gets the origin DNS name and takes over the whole DNS lookup. Client doesn't do SVCB at all. The only way to salvage SVCB-based features is to invent a header for the proxy to tell the client what SVCB path it followed in the CONNECT response. Client does SVCB lookup and gives TargetName to the proxy. Client does the whole lookup and gives the IP address to the proxy. The one that breaks empty names is (2). Though, given that proxies today are often used to access internal services (i.e. without the proxy, you may not even be able to resolve the name), I expect (1) to be the default for existing schemes. Whereas (3) might make sense for other kinds of proxy use cases. (I'm actually not entirely sure when you'd want (2) despite the spec recommendation... maybe if you're relying on the proxy to rewrite IPs, but the proxy needs to a DNS name to do so?)
This is presumably not the right forum for this topic, but mode (2) is the one that gives you correct Happy Eyeballs, geo-DNS, etc.
I seem to recall some DNS IPv6 transition thing that maybe has that property. S.
Yes, there are transition technologies that rewrite addresses. Clients get a v6 address because they only have v6, but the server address is v4. As for the general proxy problem, there is no value in any design that does not involve the client having the ECHConfig. It can't use the public IP (because it doesn't know it always), but it can still populate servername according to the value of publicname. I might have missed something there though. From David's , option 1 is a bit silly (it adds unnecessary latency), but it also gives you the best locality if your goal is to use the proxy egress as the client network location (option 2 as Ben only works if you care about the network location of the client, at which point you might as well not use a proxy). The only difference between 2 and 3 there is whether the proxy needs to perform its own name resolution, which might differ from the client (and cause problems as a result; but that's mostly just a case of insisting that clients don't choose option 2). I don't understand why it's so hard to require the use of a domain name. It shouldn't be "". Adding other forms of reference identity adds complexity to what is already a morass of horrifying complexity, so we should insist on justification for every addition. And I'm not seeing any concrete arguments in favour of the complex option. So my answer is No to both questions.
I don't agree with Martin's characterization of the proxy behaviors, but I don't think this is the place to discuss that topic anyway. To me, the main advantage of supporting IP reference identities is for origins that are not using a large-scale hosting provider, and thus cannot rely on a widely shared . Domain names are typically more closely linked to an organization than IP addresses (especially with VM hosting), and more expensive to change. An IP address ensures that the client does not populate the outer SNI, and supports a configuration where the default certificate only contains an IP address SAN. This minimizes the information visible to an adversary unless they can also identify the service that runs on this IP address (e.g. by scanning the whole DNS). An alternative to IP address in would be a flag in the ECHConfig indicating that the specified reference identity is in the default certificate (which is implicitly true for IP reference identities). This would allow clients to omit the SNI, improving small services' privacy against a passive adversary, but active adversaries could fetch the default certificate to learn the .
For everyone's consideration, we now have as an alternate solution to this problem (thanks to NAME which does two things: (1) avoids overloading a single field for two types of values (names and addresses), and (2) punts IP address validation to a future change. While I sympathize with Martin's view, it seems overly restrictive to just prohibit IP addresses outright. This change allows us to sort that out in a future change, and should make everyone happy. Thoughts?
Re , the idea is largely me going "oops, I'm sorry for the mess". :-) When I filed , I was mostly interested in the client validation. But most places with DNS strings have a semi-overlap with IP literal syntax, and RFC6066 already prohibits of IP literals. (Without declaring an actual syntax being prohibited!) So it seemed hard to resolve those questions without going one way or another on IPs. So I brought up that question too as a seemingly minor (hah) side question on the main issue. That side question has turned out to be way more messy than I anticipated. Since there isn't a strong need for IPs as public identities, but also unease to completely close that door, I propose we tweak the encoding so it's easy enough to add later (reuse the extension mechanism we're already putting in), but not actually bother in this draft.
Isn't it the case that the extension scheme would allow us to add IP addresses later, even without ?
There's lots of different ways we can accomplish this, and it'll come down to personal taste. For example: Make publicname optional in the main ECHConfig (and waste the two byte length field), and allow an extension to specify the IP address. Move publicname to a mandatory extension (as 426 does), and allow future extensions to specify addresses override the name. etc. Given the bikeshed that's happening here, it seems prudent to at least separate these things (names and addresses). If we can agree on that, then we just need to decide where we put those bits. does the job one way. If someone wants to propose an alternative PR to put the bits somewhere else, please do so!
If we're really talking about a bikeshed, then the "no change" option works for me. It's fewer bits on the wire (by 4), it is less complicated to enforce it being mandatory, and we already have it implemented. I do think that public_name being optional has some impact here. It means that you don't have a reference identity for fallback handling. I think that's probably legitimate. There might be cases where fallback is not needed.
Hmm... how do you see this working if a future extension wants to specify IP addresses as a fallback but the publicname is not allowed to be optional? I agree that there will be cases where fallback is not needed. DNS-SD is one of them. And in that case, removing the publicname field (or allowing it to be empty, or whatever) will be needed. I think addresses that pretty nicely.
Ahh, I misunderstood. It's not that the extension is mandatory to use, but it is mandatory to understand when present. Let's be really crisp about the words we use. Of course, an empty value is an equally good way to indicate that the value isn't operative. It's one byte in the less-common case to save 4 bytes in the common case. The question occurs to me: is there any possibility that you could have both a publicname extension and this hypothetical ipreference_identity extension? What would that mean? I want to be really open about my priors here: I think that extensibility along this axis is an anti-feature for ECH. The mandatory-to-understand extensions are part of what really confirmed that for me. I think that the current format would be improved by removing the extensions block.
Unclear -- I think it'd be up to the hypothetical extension to define how those things interact. I hear you. If we didn't care about IP addresses for the fallback certificate, much of this would be simplified. (And admittedly the desire to remove the extensions block would increase for me, too.) I'm going to take this to the list, since we don't seem to be getting anywhere without consensus on that point.
The draft already defines a notion of "mandatory". Although does both (let's call the other one "required"?), which I think is the minimal encoding change because... I don't think we should open that can of worms. Even though not having a fallback flow is really the server's decision, I think the client has a stake in this too. It's useful to nudge the ecosystem towards things that work well. If a server deploys without fallback, underestimating the predictability of DNS caching, it will break rarely in some clients. That sort of thing is bad UX and increases the pressure for clients to adopt insecure fallbacks. Unless there is a clear need, I don't think we should allow that. (Otherwise not setting it up is deceptively attractive for a naive server since they make fewer decision.) The extensibility story for ECH is a little funny. You send an ECHConfigList and the client ignores any ECHConfigs it can't understand. So if we say today's ECH clients require a publicname extension, future ECH clients can still support a publicip extension that relaxes the publicname requirement. Today's ECH clients will just ignore the publicip-using configs, which is the desired behavior. But I should say I have no stake in this IP mess and do not care whether we allow those. Just pick something that everyone's happy with, please. was an attempt to punt this out of the draft while keeping all the existing semantics unchanged (hence required extension; the correct reading is that it is purely an encoding change).
That point about making it hard NOT to provide a fallback makes me more inclined to reject . If the effect is just a change in encoding, it's a less efficient encoding and one that is harder to validate properly. If the effect is to make it optional under certain conditions, you have just argued effectively for why that has negative consequences.
It's really a different point and maybe deserves it's own issue but since I'm not logged into github and email works... The "critical" bit in x.509 extensions IMO didn't work. IIRC we really designed it for the basicConstraints extension, as that had to be understood by relying parties, but the result was that we more or less only had one shot at introducing any critical extensions - unless I'm forgetting stuff (which is entirely possible:-) pretty much all later attempts to add new critical extensions failed as they'd break deployed clients. We'd have been better off adding the is-a-ca flag and anything else we knew to be critical the TBSCertificate. (Again IIRC, we put both critical and non-critical stuff into extensions because the UniqueID fields in TBSCertificate that were added in x.509v2 hadn't been useful so there was a reluctance to put new fields in there at that point.) I don't see why criticality is different for ECH extensions. My bet is that any new critical extension will need a new TLS extension code point once the first ECH RFC is issued. So I'd remove the extensions fields we've defined and if not then at least get rid of the idea of criticality. Cheers, S.
NAME I filed to discuss ECHConfig.extensions -- let's try and keep this issue focused on the IP address question(s).
Addressed in , closing.
Some edge cases around the publicname: What if the public name is some random string which is not a valid DNS name? (What's the right terminology here? Same from RFC6066?) Does the client reject the ECHConfig? My feeling is yes. Imagine you have some random service accessible on a private address. Today, it can assume it'll never see in the servername field. Even if an attacker pointed at that private address, the attacker is constrained by valid DNS strings. But the public name is never directly queried in DNS. Is a server deployment allowed to use an IP certificate for the ECH rejection identity? (That was actually the original idea for the fallback flow.) If so, how do they specify it? Do they use the ASCII serialization of the IPv4 or IPv6 address? Note that IP addresses do not go in server name, so the client would need to recognize this and leave server_name empty. NAME
I imagined the outer name would be set from the config similar to how an application sets the inner name. That is, one provides a string to and, internally, the library determines whether or not that string is a valid domain name (and thus goes in the server name) or is an IP address (and thus is used to verify the IP-based cert that might come back from the server). ASCII serialization of addresses seems fine here, if one just takes that string and passes it to the function (or equivalent).
Well, OpenSSL and derivatives have a lower-level API and just take the server name as an opaque string. :-) But yeah, that seems a reasonable model. Whatever we pick, we should write it down. What do you think should happen if the public name is neither a valid DNS name, nor a valid IP address? Like . ECHConfig parse error would be my inclination.
Yeah, that seems like a configuration error on behalf of the server.
That seems like it's already an unsafe assumption, right? Malicious clients could send SQL-injection strings to vulnerable servers without ECH. I suppose ECH introduces some asymmetry; one malicious DNS server could cause N clients to send the malicious payload.
Backing up a step, if we care to protect applications from malicious/malformed DNS hostnames, it seems prudent to validate all incoming server_name values on the server, whether they came from ClientHelloInner/ClientHelloOuter or even a non-ECH ClientHello. (Assuming we're using the RFC6066 HostName definition.)
NAME yeah, that's basically what I was thinking the function would do. Would you have cycles to prep a PR to resolve this issue?
It depends. Services listening on private addresses often make a lot of assumptions. These assumptions are pretty questionable, but we put in effort to anyway because that is reality. Yes, any server listening on a network should tolerate arbitrary input and behave well. Nonetheless, the reality is private services are often buggy. Where we break soft assumptions that might have previously (mostly) worked, we should at least think about it. Here, it seems there's no point in breaking the assumption.
Ah, servers at private addresses was not even on my radar. I support client validation of ECHConfig.publicname at parse time AND server validation of all ClientHello* servername extensions. NAME Happy to do a PR.
(I don't think the ECH spec should say anything about server validation here. The server looks at whichever ClientHello it selects and does whatever it would normally do with the server name in the selected one.)
There doesn't seem to be a standard that reflects actual current practice. Chrome and Firefox accept SNIs with underscores, which are not allowed in valid DNS names (URL).
Yep, thanks for raising that, Carrick. Perhaps we should make hostname validation a SHOULD rather than MUST?
The issue doesn't sound like a MUST vs. a SHOULD but rather what they SHOULD or MUST do. I guess we could say "do whatever you usually do with the SNI."
Oh and yeah, SHOULD seems like a better idea than MUST since there are conflicting opinions about the right way to go about it.
It's a little tricky due to what layers we're talking about. Chrome doesn't particularly validate the SNI at the TLS level. Rather, we leave that to URL parsing and DNS logic earlier in the pipeline. If we've gotten far enough to make a TLS connection, we assume we're happy with the string we're passing to SNI and certificate validation. I imagine this is reasonably common: OpenSSL likewise treats the setservername API as an opaque byte string. ECH breaks this assumption by bypassing all the earlier layers. Suddenly a TLS-level construct (ECHConfig) is fabricating a DNS name on its own, and now TLS needs to pick up all the validation.
Technically couldn't DNS logic validate the DNS name in the ECHConfig?
Hi folks, PR is a little more complete now, if you get a chance :)
To close the loop on this: it could, but we're treating the ECH parts of SVCB as opaque to DNS. [edit: I miswrote "opaque to TLS" at first] I think that's desirable because TLS may introduce new ECH extensions or ECH versions that the DNS stack may not be aware of. Also, any validation on the URL parsing / DNS query path happens in the process of making a request to the DNS server at all, whereas any validation here would be a check afterwards on the result. Whatever we do, it'll end up looking like someone, DNS or TLS, implementing a check we need to write down.
To come back to this: because SNI does not support IP addresses, IP certs must be the server's default-cert, i.e. they must be served to requests that omit the SNI. Thus, we merely need a way to tell clients to omit . My suggestion is to allow to be empty, meaning "omit outer SNI".
Keeping in mind that the client uses to authenticate the server's , the client now needs to be aware of which IP address it's connecting to. I suppose this isn't a protocol concern, but it's more ergonomic when the ECHConfig contains all the information TLS needs to do ECH.
OK. As I mentioned yesterday, I think should probably be an X.509 .
I do not think GeneralName will work. There's somewhat a mismatch between what the application thinks of as identities and how those identities are encoded into X.509. GeneralName is part of the latter. What does a browser certificate verifier, which only believes in things that fit in a URL, do if it's told the identity is now an EDIPartyName? What SNI, etc., does that translate into, given that our identity-to-TLS-config algorithm takes an HTTPS origin, not an X.509 name? (Note that the type field in SNI is fiction. There is and will be .) More importantly, this glomming too many things into an already overloaded issue. If you want to pursue this, can you please fork GeneralName into a separate topic? The status quo in the existing text is that the public name is clearly only good for DNS or DNS+IP, depending on how much you believe in URL syntax. We already have a need to better specify that case, including client validation. Let's fix that, and then we can separate tackle more complex cases.
Strongly disagree. GeneralName was a reasonable guess at a thing to do 20 years ago but is no longer a structure that ought be leveraged - we have no need for EDI nor X.400 names for ECH and even tempting someone to write code for ORAddress handling is risky - there's >1 can of worms there all of which are best avoided. S.
Agree with Stephen. Using GeneralName is like hunting butterflies with an elephant gun. :)
Addressed in , closing.
This seems like it would prohibit URL NAME NAME would this be a problem for the DNS-SD case?High-level, I think that we need to agree on what this value is for first. Editorially, I think that this text needs more space to move. Trying to cram all this stuff into a single paragraph isn't doing us any favours. Make a new section for this. It's certainly important enough to do properly. My sense is that the right answer to the underlying issues is that this is a reference identity rather than something we put in servername in ClientHelloOuter. In that case, the fallback is achieved by establishing a connection and validating that the entity providing the updated configuration is able to answer for this reference identity. You then construct ClientHelloOuter in such a way as to ensure that you are able to successfully connect to that reference identity if ClientHelloInner cannot be accepted. If this is just a name, then this is over-specified. If the goal is to describe what goes in ClientHelloOuter server_name, none of the validation is necessary. If the server wants you to put junk in the field, then I don't see how that junk would be any more identifying than an identifying DNS name. You really only need special IP address rules if you intend for this to be a reference identity. The Server Name Indication (SNI) extension in TLS has a provision to provide names other than host names[1]. None have even been defined to my knowledge, but it's there. OpenSSL (and possibly others) have had a long-standing bug[2] (fixed in master) that means that different types of names will cause an error. To be clear: I live in a glass house and am not throwing stones; these things happen. However, it means that a huge fraction of the TLS deployment will not be able to accept a different name type should one ever be defined. (This issue might have been caused by the fact that the original[3] spec didn't define the extension in such a way that unknown name types could be skipped over.) Therefore we (i.e. BoringSSL, and thus Google) are proposing to give up on this and implement our parser such that the SNI extension is only allowed to contain a single host name value. (This is compatible with all known clients.) We're assuming that since this is already the de-facto reality that there will be little objection. I'm sending this mostly to record the fact so that, if someone tries to define a new name type in the future, they won't waste their time. If the community wishes to indicate a different type of name in the future, a new extension can be defined. This is already effectively the case because we wouldn't fight this level of incompatibility when there's any other option. (I think the lesson here is that protocols should have a single joint, and that it should be kept well oiled. For TLS, that means that extensions should have minimal extensionality in themselves and that we should generally rely on the main extensions mechanism for these sorts of things.) [1] URL [2] URL – note that the data pointer is not updated. [3] URL Cheers AGL Adam Langley EMAIL URL


This should probably land after . cc NAME
I don't know the answer to this question, but, from the TLS 1.3 RFC: I noticed this while testing with a pre-baked ClientHello that had both extensions. The ECH draft clearly required that the extension be removed, but I wondered about .
Given URL, URL, and URL, I'd say quite the opposite.
Ah, I see text has been added saying it must appear in the ClientHelloOuter. Thanks for the references. I was working from draft-10.
Here's a fun case. Suppose the client talks to a 0-RTT-capable, ECH-capable server. It'll send earlydata + presharedkey in ClientHelloInner, wrap that in some ClientHelloOuter, and follow it up with early data records. Now the server rejects ECH and handshakes with the ClientHelloOuter. But the client has already sent early data, so the server needs to know to skip past it. I believe this means we need to require the client mirror ClientHelloInner.earlydata in ClientHelloOuter, even though it's not actually offering to resume anything. Sending earlydata without presharedkey is slightly weird (if tolerated at all), so we might even want to recommend a fake outer presharedkey. We almost_ don't care about this: the client may as well stop the handshake at server Finished and skip the client Finished flight anyway, for purposes of the recovery flow. However: What's not what the draft currently says If the server rejects ECH, handshakes with ClientHelloOuter, and sends HelloRetryRequest, we do care about the client's second flight getting through. That second case is extra fun because the client-facing server must look for the second ClientHello too.
Wasn't this already the outcome from ? (That is, if the inner CH has a PSK, then the outer one ought have a dummy PSK, too.) As for mirroring earlydata, why can the server not just ignore the application data (as if it received earlydata and decided to ignore it)? Taking a quick look back at RFC8446, the server behavior where clients send application data without early_data is not defined, so are you concerned about that, or something else?
Well, I think we only got as far as MAY in , but yeah I think this is another reason. Regarding ignoring application data, our server implementation only skips early data if there was an early_data extension that we rejected. I believe that matches RFC8446 since it doesn't say to skip application data in general, just that case. And, yeah, that's the concern.
Since this is behavior for the client-facing server, which supports ECH, can't we specify the desired behavior in this spec? That is, we might say that a client-facing server which rejects ECH MUST ignore any early data sent by the server, or something. Would that work?
We could, but then it'd break the nice property that a plain RFC8446 server will handshake ClientHelloOuter without any fuss. This property is great for rollback safety. (Otherwise any ECH server deployment needs to be two-stage, and introduces a lower bound that you cannot rollback beyond.) And elsewhere we've tried to avoid contradicting RFC8446. Yet another option would be to tell the client to retry on certain kinds of errors if it offered 0-RTT in ClientHelloInner, but that's a bit more fuss since retries are often outside the TLS stack. (Besides, the fact that you offer 0-RTT in ClientHelloInner is all but public anyway. While we don't have a cleartext 0-RTT marker[], it's pretty obvious from timing that some post-ClientHello record came before ServerHello.) [] In TCP... I want to say QUIC does, but I could be misremembering.
True! This is fun. :-)
I'm not sure why ignoring stuff is fuss. What's the alternative? To terminate the handshake if the server receives early data? Wouldn't that be more fuss? If RFC8446 doesn't specify what to do in this situation, I'm not sure why specifying it is in contradiction to RFC8446 (as opposed to expanding on it).
I think RFC8446 does say what to do in this situation. Section 5.2 says at the bottom: URL The default for the record layer is that decryption errors are fatal (as it should be). Early data skipping is an exception to this described in section 4.2.10, and the exception only applies when the server declines an earlydata extension. Oh no, the goal is to ignore stuff. That's what makes the recovery flow work. The issue is that, in RFC8446, servers only ignore the early data if there was an earlydata extension in ClientHello which they declined. Otherwise, it's just a fatal decryption error. In order to meet that condition, ClientHelloOuter needs the early_data extension whenever ClientHelloInner does.
ACK -- thanks for closing the loop!


Not sure if this is needed, but I guess it would be another way to generate failures;-)
Good clarification! This was already somewhat in the real-ech section, so I just replaced this with a forward pointer there.


NAME thanks, updated with the additional changes.
NAME NAME NAME Feel free to merge when you get a chance
Great! Now on to Daniel's comments.


cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.


Addressing Roman's AD comments.
has 2 conflicts, not sure how to resolve, the updates look fine. Please merge.
There was a conflict with the 8174 reference being in the other branch. I added it in because it's now part of the terminology paragraph.
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7. Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.


Addresses and . The server hint came up in the context of QUIC, e.g., as a possible optimization to let clients know if they should expect any post handshake messages. cc NAME NAME
Looks like this got merged without any business days to review it :) but otherwise the text looks good, approved.
Every day is a business day! ;-)
From NAME
Fixed by .
You probably want to be clear that ticket_request cannot appear in HRR, given that you have a section on it.
Fixed in .
I'm not a huge fan of sending extensions that aren't really needed, but this seems fine. I missed the QUIC discussion (or maybe it's still in my inbox). BTW, I still like the idea of hoisting tickets to the application layer, but ekr seems to think that they belong at the TLS layer. I guess we'll just have to keep disagreeing on that point :)


This matches agreement at the last interim. We should separate this into a different draft, but for now this will make the draft match implementation.
Partially addresses . cc NAME NAME
Http3Transport currently assumes that server-initiated bidirectional streams and datagrams can only be used for WebTransport. I suggest we prefix each server-initiated bidirectional stream and datagram with a new HTTP/3 frame type for WebTransport. This way, a future standard could define it's own frame type to run alongside WebTransport.
Using an H3 frame type for server initiated bidi streams would also make the design more consistent, instead of the asymmetric design there is today. It costs a byte per bidi stream, but it seems worth it for consistency and flexibility. For datagrams, I believe that we'd want to be able to coexist with other H3 extensions, such as MASQUE, and I believe that's possible without any extra overhead by adding a Session -> Datagram flow ID mapping when a WebTransport session is created.
If it's a single byte, it's more of a stream type (like the unidirectional stream-type) than a frame type, right? There's a discussion Victor pointed me to in , where it's suggested that datagrams belonging to a WebTransport session use the Flow ID = to the Session ID. It would be nice to avoid the extra state and lookup.
Ah yes, it's more of a stream type. In that case, I'm unsure of whether there's a good way of eliminating the asymmetry. The only option I can think of is to not use a stream type for server bidi streams and only use the frame, like for the client initiated bidi streams? Thanks for the pointer to , it looks like there are a few potential designs for datagrams flow IDs. If in doubt, simpler is probably better. I'll think more about this one.
I agree we should use the same mechanics for client and server bidi streams.
After thinking about this more, not having a stream type doesn't seem so bad to me and it does provide symmetry. Stream types seem like an obvious design choice, but I believe HTTP/3 is sufficiently constrained that one could infer the stream type based on the first frame on the stream. For example, the control stream MUST start with SETTINGS. In retrospect, having both stream types and frame types is a bit awkward, and it likely would have been cleaner to only have frame types, but that ship has sailed.
After having implemented this for hackathon, I can confirm that the lack of stream preface on server-bidi streams is annoying and requires special casing (I actually simulate receiving one). Let's please add one. I took a bit of a shortcut and treated the stream preface as both a stream type AND a frame type. After peeking at the unidirectional stream input to discover that it's WT, I let the parser run on that and treat it as a frame type, making it symmetric with the bidi case. Is it possible to define a reserved frame type with the same value as the stream type?
Given HTTP/3 does not have a stream type varint for bidi streams, I think a potential way forward is to say that the first frame on the bidi stream can indicate the 'type' of the stream, but that there is no explicit type identifier on the wire. Feel free to ignore the below comment, as it's apparently unchanged from January Looking back, SETTINGS is required to be the first frame on the control stream, so the control stream type is a bit redundant and the same is true for QPACK and I believe could be true for server push? Obviously we're not going to redesign HTTP/3 stream and frame types at this stage in the process, but making bidi streams consistent for both perspectives seems preferable to me.
Discussed at IETF 110. There seems to be a general agreement that we should make server-initiated bidi streams use the same encoding as client-initiated ones (that is to say, frames). There was some interest expressed in splitting definition of server-initiated bidi streams into their own draft; NAME and NAME are to reach out to httpbis about the appropriate venue for that.
Just bringing some of the discussion from here: HTTP should provide some consistent guidance for the format of HTTP/3 extension streams. Client-bidi extension streams have to start with a frame or series of frames, to be compatible for H3. One of these frames has to identify the type of stream. This is how WT is currently specified. Unidirectional streams all start with a Stream Type, but after that are inconsistent in H3 the control stream is: Stream Type + Frames QPACK Streams are: Stream Type + QPACK instructions Push streams are: Stream Type + Preface (Push ID) + Frames Stream Type seems like a more general extension mechanism, since it can be used to completely decouple from HTTP/3 frame parsing.
I find stream types to be less extensible than frames: frames allow you to do anything that stream types do, while additionally providing more opportunity for extensibility. I would prefer server-initiated bidirectional streams to behave like client-initiated bidirectional streams instead of unidirectional streams, as that makes implementations simpler.
January Me said: So I think I'm arguing against myself and I'm going to stop. My other comments on this thread we that I didn't like was the asymmetry of WT uni streams, which currently are . My past self seemed to be advocating that we change WT uni streams to or perhaps . Do we want general guidance about how extensions should use Stream Type vs Frames on unidirectional streams -- specifically that there should be at least one frame?
The place to put that guidance would have been draft-ietf-quic-http, and I think that ship has sailed. For unidirectional streams, I like your framing proposal as that enables extension frames down the road.
Well, not too late to put out a BCP or something, especially if there's going to be some kind of formal guidance on server-initiated bidi streams. I'll open a separate issue about changing the WT uni framing.
I think this specific issue was fixed by . Please reopen if I'm wrong.


This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.


The definition was a little loose, so I rewrote it. We only need to use 0x0a and 0x0b, which is lucky and it lets us avoid much of the mess that QUIC has around bits in the type. I've also added definitions for the fields in the frame.


URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1


URL The example shows in flight 5 Certificate --------> ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished (cid=100) Does this imply that the flight 5 is send with cid = 100 or only the Finished? I would prefer to be able to send also the other handshake messages of the flight with a cid, that would make it harder to disturb handshakes by spoofed handshake messages.
In DTLS 1.2 only the Finished message is encrypted. In the current design we make use of the CIDs only once encryption is enabled. I should explain that only the Finished message contains a CID here.
See additional explanation in PR : URL
I would enjoy it, if the cid could be extended into the not encrypted handshake messages also. Is there any reason, not to do so? My consideration is to make the handshake "slightly more" protected against spoofing. The current protection in RFC6347 is limited to URL and URL . The first applies only to the CLIENTHELLO ("cookie" protection again spoofed CLIENTHELLOs). The second (MAC and Anti-Replay) is only usable after a successful handshake. If an attacker spoofs other handshake messages, the attacker may block a handshake from being successful (even if the time window for that is very small and so it would be a rather expensive attack). Using a CID would enable a implementation either to handshake even when addresses are changing during the handshake or to protect the handshake slightly more (not supporting address changes but) use the CID to validate the handshake message belonging to this handshake. I would leave the chosen strategy to the implementation, enabling implementations to flexible chose the strategy depending on the current handshake load (means: supporting address changes in handshakes as normal operation, but switch dynamically to the more protective one, if a certain relative number of handshake fails.) My current work in progress: URL contains already this feature as experimental extension. It's easy to be added to a cid implementation.
Section 4.1.2 describes an attack where an attacker injects traffic that cannot be correctly processed due to a MAC failure. The reason why MAC failures in DTLS do not lead to a connection termination (unlike in TLS) is that they are much easier to mount: an attacker only needs to know the source and destination IP and port. Section 4.2.1 talks about the cookie exchange, which has been added to prevent amplification attacks against third parties. I would argue that these two attacks are very different from what you are trying to tackle. You would like to add resiliency against on-path (?) attacks sending spoofed handshake messages. I cannot see how the CID provides that extra protection. I understand the use case of address changes during the handshake. The question is whether this is actually something real. If the IP address & port changes during the handshake then this is indeed annoying but how often does this happen?
I mentioned 4.1.2 and 4.2.1 just to sum up the current protection mechanisms. The attack, I consider, is a off-path. e.g. using PSK, someone spoofs a CLIENTKEYEXCHANGE with the identity "ghost". Now it's hard for the server to differentiate the wrong from the right CLIENTKEYEXCHANGE with identity "me". With the CID in the handshake, spoofing into the handshake will be much harder. I don't assume, that such attacks will be easy or happen frequently. But assuming something as a "theft detection" for something valuable, it may be used to block the reporting message.
I don't understand why we'd need to enable CID during handshake, and in particular on Finished? Any sane handshake will complete well before any NAT rebinding has a chance to mess with the path (note that in-flight handshake messages refresh the port bindings...). What kind of use case would that address? Is it connection migrations while handshaking? I'm not sure the "increased robustness against spoofing" argument is a very strong one: the handshake is either robust as-is or we are in trouble :-) Also, would that imply reconsidering the security analysis of the handshake? My preference instead would be to send tls12cid records only after the handshake has completed successfully, i.e. on the first application_data.
FMPOV: protects in the long period before the handshake. With the cookie you could not only spoof CLIENTHELLOs an trigger heavy functions. protects in the long period after the handshake. With the MAC filter it's also not possible to spoof messages at that period (or even repeat them). But in the short period (few seconds) of the handshake itself, I couldn't find a straight forward method, to distinguish between the right inner handshake messages and spoofed ones. Using the CID would offer a similar protection for those inner handshake messages as the cookie for the CLIENTHELLO. I don't assume, that such attack will happen too frequently. But I could assume, if someone has a high interest, such an attack may be used to "deny" a handshake of a certain peer for a certain time period, e.g. "theft detection" for one device may be blocked for a couple of minutes. Only because the CID would offer protection against this "for free", if used during the handshake, I started to try to introduce that.
Let me admit, that the attack in the inner handshake is not likely. Some implementations seems to use the 4.1.2 mechanism even in epoch 0, that may help, but introduces other risks (attack possibilities for the inner handshake). FMPOV, currently you would need too much implementation knowledge to execute such an attack. But, though in my opinion, using the CID within the handshake, offers a protection "for free", I think it's worth to be considered.
Sorry, I'm not sure I understand which kind of extra protection we'd get: when handshaking the CID is spoofable as much as the source address in the UDP packet.
Another argument for not changing the wire image of the record layer during the handshake phase is possible middleboxes interference.
The cookie of 4.2.1 is also spoofable, but for successful spoofing it must be the right cookie for that time period and address. The same applies for the CID. If combined with the address, then it protects, because a spoofer must know the CID. (And sure, it's visible and .. but the cookie is also visible. The point is also the time period, when this CID could be used for spoofing. And that's very short, comparable with the short valid time-period of the cookie.)
I'm still confused, could you characterise precisely your attacker in terms of its goal and position in the network? Thanks!
I don't want to change the wire image more, than this draft already does! With outer type and inner types nothing additional to the already defined additions is introduces, except that it is used already within the handshake. If you want, I update my wip URL and document, how to use a CID in the handshake. Then you see in wireshark, how it works.
With outer type tls12cid(25) and inner types changecipher_spec(20), alert(21), handshake(22) nothing additional to the already defined additions is introduced Yep That's the trouble. Most "enterprise security" middleboxes want to be able to look into the handshake to determine whether a connection is ok according to their policies. After the handshake completes and the connection is considered alright, they just act as blind packet forwarders. To do the handshake inspection they depend on the established wire image of the TLS/DTLS protocol. If we introduce the ability to change the wire format during handshake (as opposed to the post-handshake phase only) we might end up impairing clients that sit behind those boxes.
Goal: Deny successful handshake of a selected peer. Position: off-path, but know the peer's address and the interesting time period. Something missing?
Smells for me, that a "list of typed cid" (see ) may be used, to enable a peer behind such a box to inform the other, not to use the CID during the handshake. types: "plain" - cid only after handshake "plain+" - cid also during handshake
Just for my personal interest: can you name a middlebox, which supports DTLS?
Sorry, now you triggered me: Why should those middleboxes forward my tlscid record, when my address has changed, but block my tlscid record, when it contains a handshake? If the middleboxes are unaware of this draft, but forward my tlscid record even with changed address, I would assume, they forward my tlscid record also with a inner handshake message.
Deny successful handshake of a selected peer. Position: off-path, but know the peer's address and the interesting time period. OK, thanks very much. Frankly, the combination of perfect timing as well as the randomization provided by the source port makes the attack window pretty narrow. On the other hand, allocating state too early (i.e., allocating CIDs without strong commitment from client side) opens up an interesting amount of attack surface on server side.
This is a tricky question. Boxes like typically have scripting capabilities which give their admins lots of leeway. I do not build nor operate any of these so my direct experience is ~0, but speaking with the Symantec guys exactly about how to modify the DTLS wire image to signal the presence of CID in a middlebox-tolerant way, their feedback was "to be sure, just leave the handshake alone as much as possible"... I have no reason to doubt their assessment, also given the ways TLS 1.3 was hit in this same space.
Above I wrote nothing else. ??? what's that ??? Why should the use of cid in the inner handshake messages as well allocate anything additionally? The cid is provided in the CLIENTHELLO and/or SERVERHELLO, it's currently just not send in the inner handshake messages. But there is not more or less to allocate, if they are used with other handshake message or not.
I have also no reason to doubt them, but I'm very unsure, if an address change will then work at all with such boxes. I would really prefer to test such an address change. I couldn't find any hint, that that box supports DTLS at all.
So the critical issue seems: with TLS there are bad experience changing the records with DTLS this experience seems to be missing. Some expect them to be similar bad. I unfortunately suspect them to be either a real disaster (address change not working at all), or not that hard. Without boxes to test and/or people with DTLS-boxes experience, it will be hard to find a solution. So, try to use the mailing list to get more feedback?
Sorry, I fail to understand your argument. What to do with an unknown 5-tuple vs what to do with an unknown C-T in a context where you expect to understand the semantics of the flow seem orthogonal to me.
I don't really understand the above sentence so I know a reply is quite risky :-) Anyway, what I wanted to say is that if you want to use CID during handshake in any meaningful way, it means the party requiring it (e.g., server) needs to allocate state internally to be able to check it on receive. If this allocation is triggered only by one (or two) CH(s), it's pretty easy to mount a "CID exhaustion" attack against the server. Requiring the client to complete the handshake before promoting a "2-tuple" connection into a "CID" connection makes the attack much more demanding and therefore a lot less likely.
(some overlap in the discussion :-) so a updated my comment with the question above.) Try to explain it: Which rules should a box apply to a tls_cid record? It's only valid after a successful handshake? But, how should such a record then be assigned to that successful handshake? Either by knowing the CID (which requires to be aware of this draft), or much weaker by the address, but then it will not work with address changes.
OK, so you don't allocate something on the server side for the CID in the CLIENTHELLO until the handshake is finished? Or you send a CID in the SERVERHELLO without allocating it before the handshake is finished? May be I'm too focused on my implementation, but without an other implementation, which shows what you wrote, it's also hard for me to understand your comments.
At least, I think you target the CID the server side is using. How is it ensured, that the CID in the SERVER_HELLO is unique at least for all established connections and all ongoing handshakes, which are not terminated at that time point?
In my message above s/CID exhaustion/resource exhaustion/ sorry... And yes, you can certainly separate the act of reserving the CID when you decide to send it in the CH from creating state associated with the CID-based session lookup paraphernalia. For example you could use a big enough CID space (say 8 bytes) and reserve your CIDs by means of a monotonically increasing function. And at a later time (my proposal is after the handshake is completed successfully) you grab the memory needed for the CID based session lookup stuff...
Another point is that we'd put more bytes on the wire, increasing the risk of message fragmentation with small MTUs in a situation, the handshake, where the timing of the messaging is such that NAT timeouts are very unlikely and therefore the 5-tuple based demuxing more than adequate.
I can't see a relation of "resource exhaustion" with the usage of the CID in the handshake.
That's right. In my experience, "small MTUs" are rarely used. The highest risk is caused by a larger CLIENTHELLO, which then gets fragmented (see "resource exhaustion"). Though CID makes the CLIENTHELLO larger, it's more an argument, that CID may not be support on such path. FMPOV, a "optimal support" for peers with a very narrow link, should be moved into a other discussion.
The part with having the choice to either "protect the handshake" or "support address changes" should just leave it to the implementation, which strategy is chosen. I would go for a configurable solution, which enables a "dynamic protection", if too many handshakes are ongoing.
I had a chat with Achim and he agreed that we can leave the feature of using CIDs for handshake messages for DTLS 1.3. This will allow us to get this work done faster. DTLS 1.3 encrypts handshake messages earlier and hence already the handshake itself utilize CIDs.
NAME Thanks for your time!
Hi Hannes, Achim, Good, thanks both for taking the time to sort this out. I think it's a very reasonable choice to not introduce scope inflation at this (late) stage. One thing we still need to do though is tighten up a bit the language around when exactly the CID is put on the wire. Something like: "Once a non-empty CID is successfully negotiated, it MUST be sent on the XYZ message and on all subsequent records of the connection" would remove all the uncertainty I guess. I personally have an inclination for XYZ to be the first application data, mainly because I'd like to commit any resources only after I have full confirmation that the client is a good one. However, I don't care whatever choice we end up with, as long as it's written down precisely in 2119 language.
I'm not sure, what "commit" includes or means exactly. To verify the FINISH you will need the "keying material from the crypto context (derived from the specific mastersecret)". According URL a good estimation will be about 128 bytes. In your wording, you use them before you "commit" them? So adding a couple of bytes for CID to that storage, should not make a difference, or?
I mean making a certain CID "used" (not just reserved) and making room for the CID in a lookup table. But, as I said, I won't be unhappy if the "first CID record" happens to be something different than the application data.
From my side the specification is also free to chose, when the peer should start to use the tls_cid records.
NAME I'm still not sure, if I really understand the requirements of your approach. My current feeling is, that you store all the keying and cid stuff in a "context" and provide a address:port-lookup-table for that stored context. One finish, you then want to store this context into a cid-lookup-table. If that's the plan, a cid usage even in the handshake doesn't matter. For epoch 0 records, just still use the address:port lookup and verify the record cid with the stored one. I personally prefer a "relaxed definition", but your case will not be wrong. It just doesn't support address changes during handshake. I guess, after a period of experience, the most user will select that option and use it to secure the handshake without supporting an address change. But that would be left to future experience. After the call with NAME I think it's better not to extend this draft with that idea and instead focus on DTLS 1.3. Therefore I removed the code for this extended usage from my wip and closed this issue. In the meantime, it's really hard to collect all statements over several issues. So, if you still interested in using the RFC6347 record for the finish and start with the tls12_cid records after that, I think, open a new issues (or PR) would make it easier to fetch up this idea.
If this feature is negotiated on, then the MAC calculation changes, even if no connection ID is sent, because of . This needs to be clearly sign-posted.
My preferred interpretation is: uses the original RFC6347, section 4.1 record format URL indicated by the already used content type ids. That includes also the unchanged MAC.
Created a pull request to add clarifying text: URL
NAME it would be great, if you could explain, if you want to use the new record type with an empty CID in order to obfuscate the DTLS payload length. Please note, that currently the specification of this draft turns more into a "strict" usage (see issue ) which will not support the new record type with an empty CID.
Interesting question. Yes, I would like to be able to use the new record type to pad records, but I don't think that it is an especially important consideration. If the design is easier without that, and I suspect that it is, then I am OK with not doing that. A one-octet connection ID is not that much of a burden to pay to get this feature.
So you would then got for adding a 1 byte cid, but still use the ip-address:port to map it to the security context (keying stuff)? Or do you consider only a few connections? For me that is just one of the scenario's, I'm really afraid of! It makes the usage of cid more indeterministic, if the spec "ignores" that kind of usage instead of explicitly considering it! FMPOV, it will be easier, to support then a empty CID record indicating, that still the ip-address:port must be used instead of a 1 byte cid, but then being not strict on the mapping.
Addressed in submitted version -04
In Figure 2, parentheses are used to signify both extensions (connection_id=100) and the addition to the record header (cid=100). I suggest using a different notation here.
NAME can you take a crack at fixing this
Here is an update: URL
Updated diagram merged into the draft.


This PR is on top of
We probably need to create a new IANA registry for RRC message types. The registry should be initialised with the 3 message types we define in the draft.
Ok.


Signed-off-by: Thomas Fossati
CC NAME
We don't currently discuss any privacy implication associated with CID reuse. We should at least: document how to ensure a new CID is used during path validation in 1.3 flag that 1.2 has no way to work around linkability because CID have the same lifetime as the session


/cc NAME Signed-off-by: Thomas Fossati
In this second paragraph, does this mean T=1s or RTT=1s ?
FMPOV: (because that refers to the default timeout of DTLS 1.2 RFC6347)


Attempt to address though I'm not entirely happy with this text. Having gone through the existing text looking at "vulnerable" and "susceptible", it doesn't seem in particularly bad shape, so my comment there may have been stronger than needed.
Copied from EKR's repo Ben Kaduk wrote: "We talk in a couple places about datagram protocols being “vulnerable” or “susceptible” to DoS attacks, which leads me to at least partially read that as meaning that the protocol’s own service will be disrupted; as we know, this is not the whole story, as the reflection/amplification part can facilitate DoS attacks targeted at other services/networks. So perhaps some rewording is in order. "
NAME I would welcome a PR here.
NAME did this,


As proposed on list.
Hanno Becker points out that the current text does not cryptographically protect the CID when we have coalesced packets. I created PR to add this feature, but I think instead we should simply require that all packets have CIDs once the CID is established. This seems like a net reduction in complexity. There would be two changes here: Re-emphasize the point already in the DTLS CID spec that you abort if a CID is expected and none is found. Remove the text about allowing implicit CIDs.
NAME NAME
This was resolved by . Please re-open if that's not the case!


NAME NAME
(Probably want to fix the typo for "Fixes" in the PR title, but the content looks good to me)
DTLS 1.3 does not really change this aspect compared to earlier DTLS versions. We could reference a number of the other TLS WG documents that attempt to reduce the size of the certificate message, such as Client Certificate URL Cached Info Certificate Compression Following the guidelines in RFC 7925 Other certificate types It may be possible to use the fragmentation mechanism to send one certificate after the other in the certificate chain. Is this what you had in mind?


This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. TSV-ART Review of draft-ietf-tls-dtls13-41 Reviewer: Bernard Aboba Summary: The timeout and retransmission scheme looks workable for common cases, but could use some refinement to make it more robust. Technical Comments Handling Invalid Records Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. [BA] How does silent discard of invalid records interact with retransmission timers? Implementations which choose to generate an alert instead, MUST generate error alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. [BA] "this practice" refers to "generate an alert instead", correct? Timer Values Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if [BA] Saying "timer values are the choice of the implementation" seems odd, because it is followed by normative language. I would delete this and start the sentence with "Mishandling...". many instances of a DTLS time out early and retransmit too quickly on a congested link. Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum). Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values. Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time the value may be reset to the initial value. [BA] Is it always possible to distinguish a retransmission from a late arrival of an original packet? This seems like it could result in wrongly resetting the timer in some situations. Large Flight Sizes DTLS does not have any built-in congestion control or rate control; in general this is not an issue because messages tend to be small. However, in principle, some messages - especially Certificate - can be quite large. If all the messages in a large flight are sent at once, this can result in network congestion. A better strategy is to send out only part of the flight, sending more when messages are acknowledged. DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension [RFC7924] and certificate compression [RFC8879]. [BA] How does the implementation know how much of the flight to send? Not sure how prevalent large certs are for DTLS (e.g. compared with the self-signed certs of WebRTC), but in EAP-TLS deployments, large certs have caused problems. The EAP-TLS cert document draft-ietf-emu-eaptlscert cites some additional mechanisms for reducing certificate sizes, such as draft-ietf-tls-ctls and [RFC6066] which defines the "clientcertificateurl" extension which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. Alert Messages Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. Note that alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure. [BA] For the fatal alert case, it does seem like retransmission would be a good idea; otherwise the peer can be left hanging. Section 7.1 "Disruptions" such as reordering do not affect timers, correct? ACKs SHOULD NOT be sent for these flights unless generating the responding flight takes significant time. What is "significant time"? Editorial Comments (NITs) Section 2 The reader is also as to be familiar with [BA] "as" -> "assumed" Section 3 The basic design philosophy of DTLS is to construct "TLS over datagram transport". Datagram transport does not require nor provide reliable or in-order delivery of data. The DTLS protocol preserves this property for application data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. [BA] While low-latency streaming and gaming does use DTLS to protect data (e.g. for protection of WebRTC data channel), telephony and RTC Audio/Video uses DTLS/SRTP for key derivation only, and SRTP for protection of data. So you might want to make a distinction. Section 3.1 Note that timeout and retransmission do not apply to the HelloRetryRequest since this would require creating state on the server. The HelloRetryRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloRetryRequests. [BA] I would add "For more detail on timeouts and retransmission, see Section 5.8." Transport Layer Mapping DTLS messages MAY be fragmented into multiple DTLS records. Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. [BA] You might reference PMTU considerations described in Section 4.4. Post-handshake client authentication Messages of each category can be sent independently, and reliability is established via independent state machines each of which behaves as described in Section 5.8.1. For example, if a server sends a NewSessionTicket and a CertificateRequest message, two independent state machines will be created. As explained in the corresponding sections, sending multiple instances of messages of a given category without having completed earlier transmissions is allowed for some categories, but not for others. Specifically, a server MAY send multiple NewSessionTicket messages at once without awaiting ACKs for earlier NewSessionTicket first. Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before. In contrast, implementations MUST NOT have send KeyUpdate, NewConnectionId or RequestConnectionId [BA] "send" -> "sent" Example of Handshake with Timeout and Retransmission The following is an example of a handshake with lost packets and retransmissions. Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, which are needed to encrypt to decrypt messages found in Record 1. [BA] "encrypt to decrypt" -> "encrypt or decrypt"? Section 7.3 In the first case the use of the ACK message is optional because the peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS. For instance in the flow shown in Figure 11 if the client does not send the ACK message [BA] Figure 11 is the DTLS State Machine. Are you referring to another figure? The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached. [BA] Do you mean "maximum retransmission timemout value"?
Addressed in


Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?
NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap. However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions. With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.


As far as referring to the snake case in the main body, I went and looked at RFC 8446 and it does not refer to the snake case. I tend to think that if we make the change in 5.2 and A.2, that should be enough breadcrumbs for people to figure it out. I put them in the same order as they are in the registry and moved up newsessionticket. Triple check this change please.
This I-D registers two TLS HandshakeTypes. All of the other fields in the registry use snake_case.


Right now, my NSS patch for compatibility mode in TLS also includes changes to DTLS. Those changes include the ServerHello format changes, but NSS will ignore the session_id and never send a ChangeCipherSpec from either client or server.
Note that we probably still want to ignore CCS in DTLS - DTLS discards things that it doesn't want to see - this is about generating CCS.


Addressing issue raised by Martin at URL
Should the server reject the ClientHello if it appears as though the client is responding to a HelloVerifyRequest? What if it also contains a cookie extension?
I don't think the server should reject a ClientHello if it thinks the Client should provide a cookie previously sent with the HelloVerifyRequest. This would require the server to keep state and to implement more complex logic in the server-side. If the ClientHello contains a cookie in the ClientHello.legacycookie field in the DTLS 1.3 field then IMHO an "illegalparameter" alert has to be sent. I created a PR to add a note about this: URL There is, however, the question why whether we should omit some of the legacy fields for use with DTLS 1.3 (not in the ClientHello because it would be needed for backwards compatibility) but for the ServerHello/HelloRetryRequest.
Fixed


NAME NAME I've created a pull request to incorporate the exec binding method in the draft. This brings it in line with and also now has a reference to the draft itself. It would be great if you can quickly review the proposed text and see if you are ok with it
Now merged, after review comments received from NAME to highlight differences between the Push and Exec binding methods


Signed-off-by: David Navarro For the reasons stated in .
Hi, OMA LwM2M is using Minimum Period (pmin) and Maximum Period (pmax) attributes. The DynLink draft has this requirement: In its version 1.0, LwM2M had a different version of this requirement in the form: Thus having pmax equal to pmin was allowed. In LwM2M 1.1 we aligned this requirement with the DynLink one, making pmin equal to pmax forbidden. However, it was that having pmin equal pmax is a valid use case if the client wants the notification to be sent exactly every N seconds. Is there a strong opinion on forbidding pmax to be equal to pmin, or are people open to changing the Dynlink requirement ? Regards
NAME After the discussion at IETF 109, I think we can agree that there are no strong opinions against allowing pmax to be greater than or equal to pmin in the draft. However in order to avoid any ambiguity in interpretation, do we want reflect the discussion so far, so that the draft has pmax == pmin, specifically for this use case, ie when this condition is met, then the CoAP server sends (is it a MUST/SHOULD/MAY?) the resource representation every N seconds? Also how does the client then cancel this request?
Closing this issue, with the draft allowing pmax to have equality to pmin


"The server MAY include the same Echo option value in several different responses and to different clients." Clarification based on Jim's review.