Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi John, Hi Ekr,
Regarding the presentation language used in the document I have added a
clarification to the terminology section, see
https://github.com/tlswg/dtls-conn-id/pull/110.
I hope this addresses the issue.
Ciao
Hannes
From: Eric Rescorla
Sent: Tuesday, April 20, 2021 11:32 PM
To: John Scudder
Cc: The IESG ; draft-ietf-tls-dtls-connection...@ietf.org;
tls-chairs ; ; Joseph Salowey
Subject: Re: John Scudder's No Objection on
draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker
mailto:nore...@ietf.org>> wrote:
John Scudder 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
--
COMMENT:
--
I found this document heavy sledding but once I was through it, it all came
together, with the exception of my #3, below. The “heavy sledding” part I think
would be largely fixed by addressing my #1, below.
1. Section 3:
This pseudocode is a little too pseudo for me:
struct {
opaque cid<0..2^8-1>;
} ConnectionId;
What does the content of the angle brackets mean? At first I took it to mean
“this can take on a value from 0 to 255” [*] but parts of the spec that go on
about variable lengths made me think that couldn’t be right. Eventually, by
paging through RFC 5246, I found some explanations of what this stuff is
supposed to mean; in §4.3 of that RFC I found out that
Variable-length vectors are defined by specifying a subrange of legal
lengths, inclusively, using the notation . When
these are encoded, the actual length precedes the vector's contents
in the byte stream. The length will be in the form of a number
consuming as many bytes as required to hold the vector's specified
maximum (ceiling) length.
I assume this is what’s going on in DTLS as well. This cleared up my main
source of confusion, which was regarding just how you were encoding these
variable-length CIDs anyway. (And oh by the way, that definition doesn’t say
what the units of length are. Bytes seems implied but isn’t explicit.)
While I don’t expect you to supply these definitions again, it would be
courteous to your readers to have a sentence or two explaining that pseudo-code
conventions are found in RFC 5246, special extra credit for section references
as well. And yes, I did notice "This document assumes familiarity with DTLS 1.2
[RFC6347].” That’s well and good, but I don’t think “familiarity” is the same
as “we have adopted the same notational conventions”
This seems like a pretty basic assumption. These aren't just notational
conventions
or pseudo-code. They're the protocol description language that TLS is defined
in.
If one isn't familiar with how to read this syntax, then you really don't have
much of
a hope of correctly implementing this specification.
[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew
obfuscation!
Which one of these is clearer seems like a question of taste, I should think.
It's worth noting that because the length prefix is determined by the ceiling,
arguably 2^8-1 is clearer.
2. Section 3:
If DTLS peers have negotiated the use of a non-zero-length CID for a
given direction, then once encryption is enabled they MUST send with
the record format defined in {{dtls-ciphertext} with the new MAC
computation defined in Section 5 and the content type tls12_cid.
Plaintext payloads never use the new record type and the CID content
type.
What’s “{{dtls-ciphertext}”? I’m guessing just a botched xref?
Yes, presumably. Looks like I forgot a }}.
Also, the first sentence seems to have no object. (What MUST they send?)
send anything, but I suppose "send records". I can make a change.
3. Section 6:
* There is a strategy for ensuring that the new peer address is able
to receive and process DTLS records. No such strategy is defined
in this specification.
This is a little mind-boggling to me. I understand this to mean I can’t send
the new address a DTLS record unless I’ve already ensured it can receive and
process that record, right? This seems almost like a classic Catch-22. I feel
like I must be missing something.
This specification *only* allows you to mux, but doesn't allow you to migrate.
We could probably make this point clearer.
-Ekr
IMPORTANT NOTICE: The contents of this email and any attachments are
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi John, Hi Ekr, I hope I correctly understand the essence of your conversation. I am wondering whether a link from the bullet list to the text two paragraphs down will help. Here is my proposal: https://github.com/tlswg/dtls-conn-id/pull/111 Ciao Hannes From: John Scudder Sent: Wednesday, April 21, 2021 2:07 AM To: Eric Rescorla Cc: The IESG ; draft-ietf-tls-dtls-connection...@ietf.org; tls-chairs ; tls@ietf.org; Joseph Salowey Subject: Re: John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT) On Apr 20, 2021, at 7:24 PM, Eric Rescorla mailto:e...@rtfm.com>> wrote: On Tue, Apr 20, 2021 at 3:42 PM John Scudder mailto:j...@juniper.net>> wrote: On Apr 20, 2021, at 5:32 PM, Eric Rescorla mailto:e...@rtfm.com>> wrote: 3. Section 6: * There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification. This is a little mind-boggling to me. I understand this to mean I can’t send the new address a DTLS record unless I’ve already ensured it can receive and process that record, right? This seems almost like a classic Catch-22. I feel like I must be missing something. This specification *only* allows you to mux, but doesn't allow you to migrate. We could probably make this point clearer. Yes, I think so. Various things led me to think this was supposed to be a feature. For starters, the abstract: A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. It’s true the abstract doesn’t promise that I can migrate to the new address, but I felt led in that direction. But more to the point, §6 itself: When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following three conditions are met: If I understand your reply correctly, the quoted sentence could end “… unless the following three conditions are met (which will never happen):”. Since that seems both capricious and pointless, I still think I’m missing something. Is it that you envision a future specification that does define a strategy that will fulfill the third condition? Yes. Got it, thanks. In that case I think it brings us back to your earlier “we could probably make this point clearer”. —John IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
HI John, Am 21.04.21 um 00:42 schrieb John Scudder: 3. Section 6: * There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification. This is a little mind-boggling to me. I understand this to mean I can’t send the new address a DTLS record unless I’ve already ensured it can receive and process that record, right? This seems almost like a classic Catch-22. I feel like I must be missing something. This specification *only* allows you to mux, but doesn't allow you to migrate. We could probably make this point clearer. Yes, I think so. Various things led me to think this was supposed to be a feature. For starters, the abstract: A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. It’s true the abstract doesn’t promise that I can migrate to the new address, but I felt led in that direction. But more to the point, §6 itself: When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following three conditions are met: If I understand your reply correctly, the quoted sentence could end “… unless the following three conditions are met (which will never happen):”. Since that seems both capricious and pointless, I still think I’m missing something. Is it that you envision a future specification that does define a strategy that will fulfill the third condition? That might be worth saying, if so. Yes, see https://github.com/tlswg/dtls-conn-id/issues/103#issuecomment-822306643 best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
> That in turn implies that getting an IP-based certificate might be easier > than a DV certificate (and the associated name). I'd need more supporting > evidence to believe that. Under what conditions could that be true? I'm not making any claims at all about the ease with which one can get different types of certificates. I'm only stating that it's possible to get IP-based certificates, and people do, and thus it's possible to have a client-facing server that has an IP-based certificate. > On Apr 20, 2021, at 7:10 PM, Martin Thomson wrote: > > On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote: >>> I'm not sure what you are implying might be impossible. Are you suggesting >>> that it might be impossible to get a name for which you could get a >>> certificate? >> >> No. I'm implying that if we don't allow clients to authenticate >> client-facing servers with an IP-based certificate, ECH won't be >> possible in cases where the client-facing server doesn't have a name. > > That in turn implies that getting an IP-based certificate might be easier > than a DV certificate (and the associated name). I'd need more supporting > evidence to believe that. Under what conditions could that be true? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote: > > I'm not sure what you are implying might be impossible. Are you suggesting > > that it might be impossible to get a name for which you could get a > > certificate? > > No. I'm implying that if we don't allow clients to authenticate > client-facing servers with an IP-based certificate, ECH won't be > possible in cases where the client-facing server doesn't have a name. That in turn implies that getting an IP-based certificate might be easier than a DV certificate (and the associated name). I'd need more supporting evidence to believe that. Under what conditions could that be true? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
> In general, I'd prefer we get ECH deployed for some major use > cases and not try fill in every possible niche at this point. That's fine with me. > On Apr 20, 2021, at 7:03 PM, Stephen Farrell > wrote: > > > Hiya, > > To answer Chris' initial question: I can't currently think of > a real use-case where the client would need to authenticate > an IP address for a client-facing server in the event that > ECH decryption has been tried and failed. > > And, I very much sympathise with Martin's goal of simplifying > if we can. (E.g. leave the public_name as-is and as we've got > implemented, but drop the extensions field entirely - I don't > think there's a shortage of code points for new extensions if > the first ECH one doesn't quite do what's needed.) > > But I'm likely not the right person to ask - I'd guess that > the people who might have a use-case for this are smaller > hosters where the default listener on 443 is very minimal. I > don't know how common those are, but I'd suspect they are > fairly rare. And likely those with certs that have the > exactly right IP address are even rarer. > > On 21/04/2021 02:48, Carrick Bartle wrote: >>> I'm not sure what you are implying might be impossible. Are you >>> suggesting that it might be impossible to get a name for which you >>> could get a certificate? >> No. I'm implying that if we don't allow clients to authenticate >> client-facing servers with an IP-based certificate, ECH won't be >> possible in cases where the client-facing server doesn't have a >> name. > > In general, I'd prefer we get ECH deployed for some major use > cases and not try fill in every possible niche at this point. > ISTM the overall win here is that we end up with ECH working > in many cases, but don't need all cases. And there's a danger > that we get zero cases if we make it too complex. > > Cheers, > S. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
Hiya, To answer Chris' initial question: I can't currently think of a real use-case where the client would need to authenticate an IP address for a client-facing server in the event that ECH decryption has been tried and failed. And, I very much sympathise with Martin's goal of simplifying if we can. (E.g. leave the public_name as-is and as we've got implemented, but drop the extensions field entirely - I don't think there's a shortage of code points for new extensions if the first ECH one doesn't quite do what's needed.) But I'm likely not the right person to ask - I'd guess that the people who might have a use-case for this are smaller hosters where the default listener on 443 is very minimal. I don't know how common those are, but I'd suspect they are fairly rare. And likely those with certs that have the exactly right IP address are even rarer. On 21/04/2021 02:48, Carrick Bartle wrote: I'm not sure what you are implying might be impossible. Are you suggesting that it might be impossible to get a name for which you could get a certificate? No. I'm implying that if we don't allow clients to authenticate client-facing servers with an IP-based certificate, ECH won't be possible in cases where the client-facing server doesn't have a name. In general, I'd prefer we get ECH deployed for some major use cases and not try fill in every possible niche at this point. ISTM the overall win here is that we end up with ECH working in many cases, but don't need all cases. And there's a danger that we get zero cases if we make it too complex. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
> I'm not sure what you are implying might be impossible. Are you suggesting > that it might be impossible to get a name for which you could get a > certificate? No. I'm implying that if we don't allow clients to authenticate client-facing servers with an IP-based certificate, ECH won't be possible in cases where the client-facing server doesn't have a name. > On Apr 20, 2021, at 6:40 PM, Martin Thomson wrote: > > On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote: >> This does sound unusual. That said, if this sort of set-up is possible >> (which presumably it is), it seems unfortunate to make ECH impossible >> in that scenario. > > I'm not sure what you are implying might be impossible. Are you suggesting > that it might be impossible to get a name for which you could get a > certificate? If that could be shown to be impossible (or even just quite > hard) under some reasonable set of conditions, then I might change my > position. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote: > This does sound unusual. That said, if this sort of set-up is possible > (which presumably it is), it seems unfortunate to make ECH impossible > in that scenario. I'm not sure what you are implying might be impossible. Are you suggesting that it might be impossible to get a name for which you could get a certificate? If that could be shown to be impossible (or even just quite hard) under some reasonable set of conditions, then I might change my position. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
> we're talking about a host that fronts for multiple different names, so I'm > finding it hard to imagine how finding a name usable for this purpose would > be challenging. This does sound unusual. That said, if this sort of set-up is possible (which presumably it is), it seems unfortunate to make ECH impossible in that scenario. > On Apr 20, 2021, at 6:00 PM, Martin Thomson wrote: > > On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote: >> Taking a step back, it would be great if we could reach consensus on >> whether or not this is a use case we actually want to solve. > > The Web currently recognizes IP certificates. The specs, thanks RFC 6125, > largely missed this, but we're fixing that. ACME has RFC 8738 and the latest > HTTP(S) spec finally defines validation for an IP-based reference identity. > > All that said, IP certificates are naturally a feature with narrow > applicability. For something like ECH fallback, which should be rare, we > benefit more from reduced options and simplicity than we do by enabling niche > features. Adding a dependency on a rarely used feature, optional or not, > only increases the risk profile. And complexity. > > So I don't think we should support different anything other than a domain > name for ECH fallback. > > If someone could demonstrate that it would be an undue imposition to require > a client-facing server to use a domain name, then I would happily concede the > point. As it is, we're talking about a host that fronts for multiple > different names, so I'm finding it hard to imagine how finding a name usable > for this purpose would be challenging. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authenticating the client-facing server with an IP-based certificate
On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote: > Taking a step back, it would be great if we could reach consensus on > whether or not this is a use case we actually want to solve. The Web currently recognizes IP certificates. The specs, thanks RFC 6125, largely missed this, but we're fixing that. ACME has RFC 8738 and the latest HTTP(S) spec finally defines validation for an IP-based reference identity. All that said, IP certificates are naturally a feature with narrow applicability. For something like ECH fallback, which should be rare, we benefit more from reduced options and simplicity than we do by enabling niche features. Adding a dependency on a rarely used feature, optional or not, only increases the risk profile. And complexity. So I don't think we should support different anything other than a domain name for ECH fallback. If someone could demonstrate that it would be an undue imposition to require a client-facing server to use a domain name, then I would happily concede the point. As it is, we're talking about a host that fronts for multiple different names, so I'm finding it hard to imagine how finding a name usable for this purpose would be challenging. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Authenticating the client-facing server with an IP-based certificate
Issue #424 tracks whether or not we want to allow clients to authenticate client-facing servers with an IP-based certificate: https://github.com/tlswg/draft-ietf-tls-esni/issues/424 There are a number of different proposals for _how_ we might enable this, varying in how the name and addresses are encoded in ECHConfig structures, how these interact with atypical client connection setups (through a proxy, for example), and so on. Complexity abounds. Taking a step back, it would be great if we could reach consensus on whether or not this is a use case we actually want to solve. If it's not, then the design space seems quite smaller and more manageable in comparison. To that end, it would be great if folks could chime in here whether or not they support this particular use case (with rationale as needed). Thanks! Chris (no hat) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Apr 20, 2021, at 7:24 PM, Eric Rescorla wrote: On Tue, Apr 20, 2021 at 3:42 PM John Scudder mailto:j...@juniper.net>> wrote: On Apr 20, 2021, at 5:32 PM, Eric Rescorla mailto:e...@rtfm.com>> wrote: 3. Section 6: * There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification. This is a little mind-boggling to me. I understand this to mean I can’t send the new address a DTLS record unless I’ve already ensured it can receive and process that record, right? This seems almost like a classic Catch-22. I feel like I must be missing something. This specification *only* allows you to mux, but doesn't allow you to migrate. We could probably make this point clearer. Yes, I think so. Various things led me to think this was supposed to be a feature. For starters, the abstract: A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. It’s true the abstract doesn’t promise that I can migrate to the new address, but I felt led in that direction. But more to the point, §6 itself: When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following three conditions are met: If I understand your reply correctly, the quoted sentence could end “… unless the following three conditions are met (which will never happen):”. Since that seems both capricious and pointless, I still think I’m missing something. Is it that you envision a future specification that does define a strategy that will fulfill the third condition? Yes. Got it, thanks. In that case I think it brings us back to your earlier “we could probably make this point clearer”. —John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
> On Apr 20, 2021, at 7:33 PM, Rob Sayre wrote: > > The ECH (nee ESNI) spec says "All TLS notation comes from [RFC8446], Section > 3." Something like that should work fine here, in "Conventions and > Terminology". Yes, that would be fine from my point of view. —John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Tue, Apr 20, 2021 at 3:42 PM John Scudder wrote: > On Apr 20, 2021, at 5:32 PM, Eric Rescorla wrote: > > This seems like a pretty basic assumption. These aren't just notational > conventions > or pseudo-code. They're the protocol description language that TLS is > defined in. > If one isn't familiar with how to read this syntax, then you really don't > have much of > a hope of correctly implementing this specification. > > > Be that as it may, the point about courtesy to the naïve reader stands. > The ECH (nee ESNI) spec says "All TLS notation comes from [RFC8446], Section 3." Something like that should work fine here, in "Conventions and Terminology". It is true that most TLS projects have generic code for dealing with this syntax. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Tue, Apr 20, 2021 at 3:42 PM John Scudder wrote: > On Apr 20, 2021, at 5:32 PM, Eric Rescorla wrote: > > 3. Section 6: >> >>* There is a strategy for ensuring that the new peer address is able >> to receive and process DTLS records. No such strategy is defined >> in this specification. >> >> This is a little mind-boggling to me. I understand this to mean I can’t >> send >> the new address a DTLS record unless I’ve already ensured it can receive >> and >> process that record, right? This seems almost like a classic Catch-22. I >> feel >> like I must be missing something. > > > This specification *only* allows you to mux, but doesn't allow you to > migrate. > We could probably make this point clearer. > > > Yes, I think so. Various things led me to think this was supposed to be a > feature. For starters, the abstract: > >A CID is an identifier carried in the record layer header that gives >the recipient additional information for selecting the appropriate >security association. In "classical" DTLS, selecting a security >association of an incoming DTLS record is accomplished with the help >of the 5-tuple. If the source IP address and/or source port changes >during the lifetime of an ongoing DTLS session then the receiver will >be unable to locate the correct security context. > > > It’s true the abstract doesn’t promise that I can migrate to the new > address, but I felt led in that direction. But more to the point, §6 itself: > >When a record with a CID is received that has a source address >different than the one currently associated with the DTLS connection, >the receiver MUST NOT replace the address it uses for sending records >to its peer with the source address specified in the received >datagram unless the following three conditions are met: > > > If I understand your reply correctly, the quoted sentence could end “… > unless the following three conditions are met (which will never happen):”. > Since that seems both capricious and pointless, I still think I’m missing > something. Is it that you envision a future specification that does define > a strategy that will fulfill the third condition? > Yes. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Apr 20, 2021, at 5:32 PM, Eric Rescorla mailto:e...@rtfm.com>> wrote: This seems like a pretty basic assumption. These aren't just notational conventions or pseudo-code. They're the protocol description language that TLS is defined in. If one isn't familiar with how to read this syntax, then you really don't have much of a hope of correctly implementing this specification. Be that as it may, the point about courtesy to the naïve reader stands. [*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew obfuscation! Which one of these is clearer seems like a question of taste, I should think. It's worth noting that because the length prefix is determined by the ceiling, arguably 2^8-1 is clearer. I don’t follow your point, but suit yourself. 3. Section 6: * There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification. This is a little mind-boggling to me. I understand this to mean I can’t send the new address a DTLS record unless I’ve already ensured it can receive and process that record, right? This seems almost like a classic Catch-22. I feel like I must be missing something. This specification *only* allows you to mux, but doesn't allow you to migrate. We could probably make this point clearer. Yes, I think so. Various things led me to think this was supposed to be a feature. For starters, the abstract: A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. It’s true the abstract doesn’t promise that I can migrate to the new address, but I felt led in that direction. But more to the point, §6 itself: When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following three conditions are met: If I understand your reply correctly, the quoted sentence could end “… unless the following three conditions are met (which will never happen):”. Since that seems both capricious and pointless, I still think I’m missing something. Is it that you envision a future specification that does define a strategy that will fulfill the third condition? That might be worth saying, if so. Thanks, —John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:
> John Scudder 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
>
>
>
> --
> COMMENT:
> --
>
> I found this document heavy sledding but once I was through it, it all came
> together, with the exception of my #3, below. The “heavy sledding” part I
> think
> would be largely fixed by addressing my #1, below.
>
> 1. Section 3:
>
> This pseudocode is a little too pseudo for me:
>
> struct {
> opaque cid<0..2^8-1>;
> } ConnectionId;
>
> What does the content of the angle brackets mean? At first I took it to
> mean
> “this can take on a value from 0 to 255” [*] but parts of the spec that go
> on
> about variable lengths made me think that couldn’t be right. Eventually, by
> paging through RFC 5246, I found some explanations of what this stuff is
> supposed to mean; in §4.3 of that RFC I found out that
>
>Variable-length vectors are defined by specifying a subrange of legal
>lengths, inclusively, using the notation . When
>these are encoded, the actual length precedes the vector's contents
>in the byte stream. The length will be in the form of a number
>consuming as many bytes as required to hold the vector's specified
>maximum (ceiling) length.
>
> I assume this is what’s going on in DTLS as well. This cleared up my main
> source of confusion, which was regarding just how you were encoding these
> variable-length CIDs anyway. (And oh by the way, that definition doesn’t
> say
> what the units of length are. Bytes seems implied but isn’t explicit.)
>
> While I don’t expect you to supply these definitions again, it would be
> courteous to your readers to have a sentence or two explaining that
> pseudo-code
> conventions are found in RFC 5246, special extra credit for section
> references
> as well. And yes, I did notice "This document assumes familiarity with
> DTLS 1.2
> [RFC6347].” That’s well and good, but I don’t think “familiarity” is the
> same
> as “we have adopted the same notational conventions”
>
This seems like a pretty basic assumption. These aren't just notational
conventions
or pseudo-code. They're the protocol description language that TLS is
defined in.
If one isn't familiar with how to read this syntax, then you really don't
have much of
a hope of correctly implementing this specification.
> [*] By the way, why not just use “255” in the text instead of “2^8-1”?
> Eschew
> obfuscation!
>
Which one of these is clearer seems like a question of taste, I should
think.
It's worth noting that because the length prefix is determined by the
ceiling,
arguably 2^8-1 is clearer.
2. Section 3:
>
>If DTLS peers have negotiated the use of a non-zero-length CID for a
>given direction, then once encryption is enabled they MUST send with
>the record format defined in {{dtls-ciphertext} with the new MAC
>computation defined in Section 5 and the content type tls12_cid.
>Plaintext payloads never use the new record type and the CID content
>type.
>
> What’s “{{dtls-ciphertext}”? I’m guessing just a botched xref?
>
Yes, presumably. Looks like I forgot a }}.
Also, the first sentence seems to have no object. (What MUST they send?)
>
send anything, but I suppose "send records". I can make a change.
3. Section 6:
>
>* There is a strategy for ensuring that the new peer address is able
> to receive and process DTLS records. No such strategy is defined
> in this specification.
>
> This is a little mind-boggling to me. I understand this to mean I can’t
> send
> the new address a DTLS record unless I’ve already ensured it can receive
> and
> process that record, right? This seems almost like a classic Catch-22. I
> feel
> like I must be missing something.
This specification *only* allows you to mux, but doesn't allow you to
migrate.
We could probably make this point clearer.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
John Scudder 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
--
COMMENT:
--
I found this document heavy sledding but once I was through it, it all came
together, with the exception of my #3, below. The “heavy sledding” part I think
would be largely fixed by addressing my #1, below.
1. Section 3:
This pseudocode is a little too pseudo for me:
struct {
opaque cid<0..2^8-1>;
} ConnectionId;
What does the content of the angle brackets mean? At first I took it to mean
“this can take on a value from 0 to 255” [*] but parts of the spec that go on
about variable lengths made me think that couldn’t be right. Eventually, by
paging through RFC 5246, I found some explanations of what this stuff is
supposed to mean; in §4.3 of that RFC I found out that
Variable-length vectors are defined by specifying a subrange of legal
lengths, inclusively, using the notation . When
these are encoded, the actual length precedes the vector's contents
in the byte stream. The length will be in the form of a number
consuming as many bytes as required to hold the vector's specified
maximum (ceiling) length.
I assume this is what’s going on in DTLS as well. This cleared up my main
source of confusion, which was regarding just how you were encoding these
variable-length CIDs anyway. (And oh by the way, that definition doesn’t say
what the units of length are. Bytes seems implied but isn’t explicit.)
While I don’t expect you to supply these definitions again, it would be
courteous to your readers to have a sentence or two explaining that pseudo-code
conventions are found in RFC 5246, special extra credit for section references
as well. And yes, I did notice "This document assumes familiarity with DTLS 1.2
[RFC6347].” That’s well and good, but I don’t think “familiarity” is the same
as “we have adopted the same notational conventions”.
[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew
obfuscation!
2. Section 3:
If DTLS peers have negotiated the use of a non-zero-length CID for a
given direction, then once encryption is enabled they MUST send with
the record format defined in {{dtls-ciphertext} with the new MAC
computation defined in Section 5 and the content type tls12_cid.
Plaintext payloads never use the new record type and the CID content
type.
What’s “{{dtls-ciphertext}”? I’m guessing just a botched xref?
Also, the first sentence seems to have no object. (What MUST they send?)
3. Section 6:
* There is a strategy for ensuring that the new peer address is able
to receive and process DTLS records. No such strategy is defined
in this specification.
This is a little mind-boggling to me. I understand this to mean I can’t send
the new address a DTLS record unless I’ve already ensured it can receive and
process that record, right? This seems almost like a classic Catch-22. I feel
like I must be missing something.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Martin Duke 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ -- COMMENT: -- Thanks for this document. Section 9.3.3 of quic-transport, which deals with basically the same security model, also requires the receiving endpoint to probe the original address, not just the new one, to address a somewhat more difficult attack. It would be good to at least RECOMMEND this behavior for DTLS applications, and/or (repeat/informatively reference) the logic there. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi Francesca, thank you for your review.
The ticket to track your review is:
https://github.com/tlswg/dtls-conn-id/issues/106
cheers!
On Tue, Apr 20, 2021 at 5:22 PM Francesca Palombini via Datatracker
wrote:
>
> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work on this document. I only have minor comments and nits
> below.
>
> Francesca
>
> 1. -
>
>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.
>
> 2. -
>
>the record format defined in {{dtls-ciphertext} with the new MAC
>
> FP: nit - missing "}" in markdown.
>
> 3. -
>
>The following MAC algorithm applies to block ciphers that use the
>with Encrypt-then-MAC processing described in [RFC7366].
>
> FP: remove "with"
>
> 4. -
>
> 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.
>
> 5. -
>
> Section 10.2
>
> FP: Just checking - why is 53 "incompatible with this document"?
>
> 6. -
>
>Value Extension Name TLS 1.3 DTLS Only Recommended Reference
>
> FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--
Thomas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hello Francesca,
> 5. -
>
> Section 10.2
>
> FP: Just checking - why is 53 "incompatible with this document"?
The 53 was is used with the MAC definition of the previous version 06 of
this draft. Though the MAC has been adapted, using a different extension
number makes it easier to migrate existing deployments to that new MAC.
At least for Eclipse/Californium I know, that is used with 53 and the
old MAC.
best regards
Achim Kraus
Am 20.04.21 um 18:22 schrieb Francesca Palombini via Datatracker:
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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
--
COMMENT:
--
Thank you for the work on this document. I only have minor comments and nits
below.
Francesca
1. -
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.
2. -
the record format defined in {{dtls-ciphertext} with the new MAC
FP: nit - missing "}" in markdown.
3. -
The following MAC algorithm applies to block ciphers that use the
with Encrypt-then-MAC processing described in [RFC7366].
FP: remove "with"
4. -
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.
5. -
Section 10.2
FP: Just checking - why is 53 "incompatible with this document"?
6. -
Value Extension Name TLS 1.3 DTLS Only Recommended Reference
FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Francesca Palombini's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
--
COMMENT:
--
Thank you for the work on this document. I only have minor comments and nits
below.
Francesca
1. -
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.
2. -
the record format defined in {{dtls-ciphertext} with the new MAC
FP: nit - missing "}" in markdown.
3. -
The following MAC algorithm applies to block ciphers that use the
with Encrypt-then-MAC processing described in [RFC7366].
FP: remove "with"
4. -
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.
5. -
Section 10.2
FP: Just checking - why is 53 "incompatible with this document"?
6. -
Value Extension Name TLS 1.3 DTLS Only Recommended Reference
FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
