Re: Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
On Tue, 30 Nov 2010, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Datagram Transport Layer Security version 1.2' draft-ietf-tls-rfc4347-bis-04.txt as a Proposed Standard A bit late to the IETF LC, but hopefully these are still useful. This is an ops-dir review of draft-ietf-tls-rfc4347-bis-04 (DTLS 1.2). This looks good, but the text seems a bit unclear on IP fragmentation vs packetization. ICMP notifications passing up to the app is only a 'should' and this begs the question why. IANA considerations practicalities could also be spelled out (not sure how detailed IANA wants these to be). In more detail: If I understand correctly *), initial DTLS exchanges will typically use fragmented UDP packets due certificate sizes etc. The likelyhood of getting fragmented IP packets through firewalls and other devices is significantly lower than getting UDP packets through. The spec would be more robust and the protocol likely more applicable in the face of these 'network effects' if it tried to do packetization itself in such a manner that IP fragmentation would not be necessary. *) S 3.2.3 and 4.1.1 appear to be somewhat contradictory on this. See below. The document does not have a Changes from DTLS 1.0 (RFC4347) section that is is mandated or at least strongly recommended for update-specs. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well. specific comments - 3.2.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to 1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid 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. ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error. .. is this too weak? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure. 7. IANA Considerations This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. ... this may be inadequate. I was unable to find from the registry (tls-parameters) which of these parameters this applies to. All of them? (This was triggered by S 4.1.2.5, so at least new Cipher Suites must indicate this.) If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables DTLS-OK? or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own. editorial - ... For the completeness, when referring to PMTU discovery, in addition to RFC1191 one should probably also refer to RFC1981 (the IPv6 version). [WHYIPSEC] Bellovin, S., Guidelines for Mandating the Use of IPsec, Work in Progress, October 2003. ... this should probably be rfc5406? [IKEv2]C. Kaufman (ed), Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. Kaufman, C., Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. ... remove the latter 'reference' (edit glitch?) ___ Ietf mailing list Ietf@ietf.org
Re: Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
* Pekka Savola: If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error. .. is this too weak? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure. ICMP packet too big is typically handled by the stack, not the application. The stack updates the stored path MTU, the application tries again, and this time, the stack produces smaller fragments. AFAIUI, requiring ICMP processing in applications prescribes an implementation model based on connected UDP sockets (in the terminology of the BSD sockets API). This is not always desirable or possible. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
No objections. Radia On Sun, Dec 19, 2010 at 10:16 AM, Donald Eastlake d3e...@gmail.com wrote: My apologies for responding slowly, I was traveling. If it is tolerable to people, I do not mind adding the two sentences requested by Sam to the isis-trill draft. Thanks, Donald PS: It appears to me that the same considerations apply to draft-ietf-isis-ieee-aq. On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman hartmans-i...@mit.edu wrote: Erik == Erik Nordmark nordm...@acm.org writes: Erik Adding just this sentence to draft-ietf-isis-trill (the code Erik point document) seems odd. Your comment is really a comment on Erik the security of IS-IS, and not specific to TRILL and unrelated Erik to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. ___ secdir mailing list sec...@ietf.org https://www.ietf.org/mailman/listinfo/secdir ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Radia == Radia Perlman radiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-roll-routing-metrics-14
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-routing-metrics-14 Reviewer: Roni Even Review Date:2010-12-20 IETF LC End Date: 2011-1-5 IESG Telechat date: Summary: This draft is almost ready for publication as an Standard track RFC. Major issues: No Major issues Minor issues: 1. In section 2.1 after figure 1 you specify the different fields. Please specify the size in bits of the flags field the A-field and the prec field. 2. In section 2.1 in example 1 how is it known that all nodes MUST be main powered. Do you need to provide a value to prec field? 3. In section 3.1 and throughout the document when you define the different object you have recommended value=xx. I think that since this draft defines the table and create the initial table in the IANA consideration section these are the actual values. So maybe say that these are the actual values as specified in section 6 (6.1) 4. In section 3.1 the flag field - how many bits, specify. 5. In section 3.2 figure 4 shows a flag field, how many bits, what is the value. 6. In section 6 according to rfc5226 IETF consensus is now IETF review. 7. In section 6.1 you should say that the table has the initial values and add which numbers are available for allocation. 8. In section 6.2 what values are available for allocation. Also say that currently the table is empty. 9. In section 6.2 is there a reason to create an empty table. Why not do it when there is a request to define a TLV 10.In section 6.3, are there more values allowed, can they be allocated. If not why have it managed by IANA. 11.After the table in section in section 6.3 there is a request to create another table. Maybe it should be in a separate section. 12.In section 6.3 New bit numbers may be allocated, how many bits are available. 13.The same paragraph in section 6.3 also talks about the registration policy, is it different from the one that is common in section 6, why specify it again. Also look at comment 6 14.Comment 12 and 13 are also true for section 6.4 and 6.5. Nits/editorial comments: 1. In section first paragraph object should be object 2. In section 4.3.2 first paragraph wich should be which ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman hartmans-i...@mit.edu wrote: Radia == Radia Perlman radiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Donald == Donald Eastlake d3e...@gmail.com writes: Donald Hi, Donald On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman hartmans-i...@mit.edu wrote: Radia == Radia Perlman radiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. Donald LSPs have sequences number, etc., and are idempotent. I Donald think only Hellos have the potential replay Denial of Donald Service problem. So I would suggest changing to: Donald Even when the IS-IS authentication is used, replays of Donald Hello packets can create denial-of-service conditaions; see Donald RFC 6039 for details. These issues are similar in scope to Donald those discussed in section 6.2 of Donald draft-ietf-trill-rbridge-protocol, and the same mitigations Donald may apply. Based on my understanding your correction is accurate; thanks. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
On 20/12/2010 18:43, Donald Eastlake wrote: Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Radia == Radia Perlmanradiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. Thanks, Donald ... as I recall from discussions with the ISIS WG the changes that were made to ISIS for TRILL make it more vulnerable to a hello attack than vanilla ISIS. This I understand is because there is more work to be done in processing a TRILL hello. Is that correct? - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Hi, On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant stbry...@cisco.com wrote: On 20/12/2010 18:43, Donald Eastlake wrote: Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Radia == Radia Perlmanradiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. Thanks, Donald ... as I recall from discussions with the ISIS WG the changes that were made to ISIS for TRILL make it more vulnerable to a hello attack than vanilla ISIS. This I understand is because there is more work to be done in processing a TRILL hello. Is that correct? I think we are talking about Denial of Service due to replay of old Hellos screwing up the state. This is unrelated to the work required to process a Hello. It is true that some processing is required for IS-IS LAN Hellos. One reason for having a protocol like BFD is that you can send BFD messages more frequently because they take less processing than Hellos. But I don't see why there would be that much difference between the work involved in processing a TRILL LAN Hello and a Layer 3 IS-IS LAN Hello. - Stewart Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'IMAP LIST extension for special-use mailboxes' to Proposed Standard (draft-ietf-morg-list-specialuse-06.txt)
The IESG has approved the following document: - 'IMAP LIST extension for special-use mailboxes' (draft-ietf-morg-list-specialuse-06.txt) as a Proposed Standard This document is the product of the Message Organization Working Group. The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-morg-list-specialuse/ Technical Summary Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new mailbox attributes that a server MAY include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. Working Group Summary There were some concerns about the number of IMAP CAPABILITY strings and about moving of existing special-use attributes, but there have been no complaints about the end result. Document Quality This extension is based on Google's XLIST extension for GMail. Google has expressed interest in implementing this extension as well, among several other server vendors. Many clients have already implemented XLIST, and they will either automatically or with very small modifications gain support for this extension Personnel Timo Sirainen is the Document Shepherd for this document. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 7, please replace the 1st paragraph to read: OLD: LIST response: There are no security issues with conveying special- use information to a client. NEW: LIST response: Conveying special-use information to a client exposes a small bit of extra information that could be of value to an attacker. Knowing, for example, that a particular mailbox contains pointers to every message the user has (\All) might be of particular value. If the IMAP channel is not protected from passive eavesdropping, this could be an issue. In Section 8.6: OLD: Name: /shared/specialuse NEW: Name: /private/specialuse ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Approval of image/svg+xml Media Type
Media Type Registration Reviews - Standards Tree/No Internet Draft The IESG has approved a request to register the image/svg+xml Internet media type in the standards tree. This media type is a product of the W3C. The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. The registration template can be found at this location: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01147.html Comments on ietf-ty...@iana.org mailing list were received and addressed. An archive of the discussion can be found here: http://www.imc.org/ietf-xml-mime/mail-archive/msg00981.html http://www.alvestrand.no/pipermail/ietf-types/2010-June/002360.html http://www.ietf.org/mail-archive/web/ietf-types/current/msg01010.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Requirements for a Protocol to Replace AppleTalk NBP' to Informational RFC (draft-cheshire-dnsext-nbp-09.txt)
The IESG has approved the following document: - 'Requirements for a Protocol to Replace AppleTalk NBP' (draft-cheshire-dnsext-nbp-09.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-cheshire-dnsext-nbp/ Technical Summary One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement. Working Group Summary This was originally slated for the ZeroConf Working Group, though was abandoned a long time ago. This requirements document is part of the Bonjour protocol set from Apple, which is now fairly widely used with multiple interoperable implementations. This is being published for the good of those in the community that wish to have a stable reference of how the protocol works, and why it was designed the way it was. Document Quality An earlier revision of this document was reviewed by the IETF and the IESG. The current revision has been updated based on feedback from the earlier reviews. Ralph Droms reviewed the current revision. Personnel Ralph Droms is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
