Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC
Section 8 states Applications MUST not set contradictory flags at the same time. I think the document should specify what the API must do if contradictory flags are set. That would be the normative MUST, not the above statement of the obvious. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC
Brian, Section 8 states Applications MUST not set contradictory flags at the same time. I think the document should specify what the API must do if contradictory flags are set. That would be the normative MUST, not the above statement of the obvious. Thanks for your review, Brian! I agree with the principle that you state above. However, the document does have a definition of contradictory flags (Section 2) and explicitly describes what the API must do when getting them (Section 6) i.e., causes error EINVAL. Or EAI_BADEXTFLAGS for getaddrinfo (Section 7). I do agree though that there's something wrong in the text in Section 10 about application requirements. Perhaps s/MUST not/should not/. This may apply to some other text in Section 10, too. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC
On 2007-05-21 12:47, Jari Arkko wrote: Brian, Section 8 states Applications MUST not set contradictory flags at the same time. I think the document should specify what the API must do if contradictory flags are set. That would be the normative MUST, not the above statement of the obvious. Thanks for your review, Brian! I agree with the principle that you state above. However, the document does have a definition of contradictory flags (Section 2) and explicitly describes what the API must do when getting them (Section 6) i.e., causes error EINVAL. Or EAI_BADEXTFLAGS for getaddrinfo (Section 7). Ah, sorry, I'd missed that. I do agree though that there's something wrong in the text in Section 10 about application requirements. Perhaps s/MUST not/should not/. This may apply to some other text in Section 10, too. Yes, I think it is strange to use the normative words in this way. Brian -- NEW: Preferred email for non-IBM matters: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-sip-e2m-sec-05.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Apologies for the late arrival of these comments. Document: draft-ietf-sip-e2m-sec-05.txt Reviewer: Elwyn Davies Review Date: 18 May 2005 IETF LC End Date: 14 May 2005 IESG Telechat date: (if known) - Summary: I think this document needs a fair bit of work before it is ready to go to the IESG. The request to publish as PS to facilitate IANA registration rather than experimental (as merited by the content) appears to be spurious. AFAICS RFC 3261 only requires IETF consensus through an RFC of some suitable kind, not necessarily standards track. The document should be published as experimental. Although this proposed protocol is to be experimental, I believe that the specification as it stands is not sufficiently clear to be able to generate a well-defined result, let alone interoperable implementations. At least part of the problem is linguistic: there are parts of the document that are difficult to decode and the document would benefit from a co-author/editor with greater English language skills. I have flagged some (but not all) of these places below. Apart from issues of document clarity, I think there are several issues that need to be clarified: - Handling integrity and/or confidentiality: The introduction is less than clear that the protocol offers options for integrity alone and combined with confidentiality. I would like to see a much clearer statement of what can be achieved and the variants that can apply to different proxies etc. up front in the introduction and then carried through the document. - Clearer statements on what is protected by integrity (always the whole message?) and confidentiality (potentially different parts depending on proxy destination). Some diagrams (or tables) showing the *complete* sip message with the added e2m security pieces indicating the total message structure and what is protected in each case. - Several pieces (especially around integrity) offer multiple options for ways of doing things. Whilst this is an experimental protocol, and hence some flexibility is desirable, I think there may be too many options - maybe this will get reduced after experiment but it would be good to say this or alternatively to choose one option now. I am also not sure, particularly as regards carrying integrity information in SIP identity, that the recipient is able to determine what has been done by the sender in well-defined way. There appeared to be a certain amount of hand-waving about this and the identity case is not mentioned in the detailed descriptions of behaviour. - The protocol allows for using either pre-shared keys or exchanging certificates. I think there is an issue in the case where a pre-shared key is used and, for whatever reason, the proxy is unable to decipher the results. The specification expects to be able to send back a certificate with a key that the sender can use, but this is either not possible (if pre-shared keys are the only thing the proxy has) or may have some security issues if the proxy is allowed to substitute keys in this way. Basically, the two cases get intertwined which doesn't seem desirable. There are a few more detailed points below. Comments: Abstract: The proposed status is PS although the second para of the abstract admits that the protocol is experimental. This is justified because of the alleged need to have a standards track document for IANA registration. AFAICS from the IANA web site and RFC3261, this is incorrect. Registration requires IETF concensus manifested by means of a published RFC (presumably of a type that submits to IETF Last Call.. like this one). I see no reason why this should not be published as experimental to correctly reflect the status of the content. s1, para 2: s/consists of/may require some or all of/ s1, para 4: 'The proposed mechanisms are based on S/MIME [3], since the major requirement is to have little impact on standardized end-to-end security mechanisms defined in [1], the way of handling S/MIME-secure messages.' The last part of this does not make sense. Maybe s/the way of handling/which already uses/? s2.1, para 1: Expand CMS acronym. s2.1, para 3: The MUSTs in this paragraph are pointless and slightly confusing. Only the source UA knows which proxies and UAS are targeted, so a recipient cannot do any checks to verify that what is there satisfies the MUST. All that is being is stated is that it is a good thing if the list contains exactly the intended recipients and the relevant keys. s2.1, Figures 1 and 2 titles: s/for Sharing/to be Shared/ s2.2, para 1: 'Generating the signature requires the generator, i.e., the UA, has its own public and
IETF Meeting Host and Sponsor Program
All; There are three opportunities each year to be a Host and Sponsor of an IETF meeting in venues throughout the world. The IETF calendar with the regions targeted for the meetings can be found at: http://www3.ietf.org/meetings/0mtg-sites.txt. The Host may even suggest a particular city for the meeting, and if a qualified venue can be identified for the meeting dates, such suggestions are given considerable weight when the venue is selected. Information about hosting or sponsoring an IETF Meeting can be found at: http://www3.tools.ietf.org/group/iaoc/wiki/HostSponsorships More information about the benefits, costs, and responsibilities of hosting or sponsoring an IETF meeting can be obtained by contacting Terry Monroe at Monroe at isoc.org. Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Meeting Calendar 2011 - 2013 #2
All; Based upon feedback received an adjustment was made in March of 2013. Please advise if any further modification to the proposed IETF Meeting schedule below is desired. Thanks Ray Pelletier IAD 2011 16IETF 80Mar 27 - Apr 1 17IETF 81Jul 24 - 29 18IETF 82Nov 13 - 18 2012 21IETF 83Mar 25 - 30 22IETF 84Jul 29 - Aug 3 23IETF 85Nov 4 - 9 2013 26IETF 86Mar 17 - 22 27IETF 87Jul 28 - Aug 2 28IETF 88Nov 3 - 8 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On 5/19/07, Tim Bray [EMAIL PROTECTED] wrote: Well Rob, I think the community at large and the IESG in particular would welcome suggestions on what to do with this one. Sorry Tim, can't agree with that assertion. At least some people seem to be content with handwaving, if the current Atompub spec is any indication of consensus. In fact, we know what's going to happen: There's no need for the future tense, since a reasonable number of implementations exist. Here's a python implementation of TLS 1.1: http://pkgsrc.se/security/py-tlslite It comes with a demo HTTP server. See how many clients can connect when you use the mandatory cipher from TLS 1.1, and credentials that contain things like Chinese characters, Euro symbols, and smartquotes. On the plus side, you won't have any problems with authentication databases, because the credentials sent are reusable with any message and authentication scheme, at any time. -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On Sunday, May 20, 2007 01:41:29 PM -0700 Eric Rescorla [EMAIL PROTECTED] wrote: I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't really something that can be decided on technical grounds: the protocols are very slightly different and (at least in theory) backward compatible. TLS 1.1 is slightly more secure and TLS 1.0 is quite a bit more widely deployed. On balance, I think this probably turns into a MUST for 1.0 and a SHOULD for 1.1, but I could certainly see this argued another way. It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstraction -- except that the situation is not as painful, because using a different version of IP means you have to use completely different names, whereas using a different version of TLS does not. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
On Mon, 21 May 2007, Jeffrey Hutzelman wrote: ... It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstraction -- except that the situation is not as painful, because using a different version of IP means you have to use completely different names, whereas using a different version of TLS does not. We expect application protocols that require TLS to specify a mandatory- -to-implement ciphersuite to guarantee interoperability between clients and servers. How is the TLS version any different? A client that only supports TLS 1.0 will fail at handshake time if the server only supports TLS 1.1. Therefore, if interoperability is the goal, requiring support for a specific version is necessary. While there are some potential library versioning issues for TLS, the fact that the protocol has version negotiation built in means the likely result is everyone will support old versions for longer than we all wish: how many clients send still send SSLv2-compatible handshake messages, even when using doing in-protocol upgrade (ala STARTTLS) where both ends are required to implement TLS? (This contrasts with the real versioning issues for Unicode libraries, where the lack of backwards compatibility with the normalization output of earlier versions has been an issue.) The TLS/SSL version/cipher-suite negotiation has its own risks, of course. If an earlier version and/or offered cipher-suite is catastrophically broken or just Too Weak, then the client cannot safely offer them. So, if the goal of the MtI requirement is security, then the spec needs to require a minimum version from servers *and* that clients not offer an earlier version, no? Back to your comment, I'm not sure what you mean by have to use completely different names. A name in DNS can have both A and records, as demonstrated by www.ietf.org. Code using getaddrinfo() may automatically try both, though the order they are returned in is an implementation detail. (That it's not clear whether getaddrinfo() is responsible for ordering them is probably another strike against it on Keith's list.) As for calling out a specific version of IP, there was recently a thread in the discussion around RFC 2821bis (821ter?) regarding whether it should have some normative wording against sending messages whose envelope sender (bounce address) can only be reached using IPv6**, as delivery failure notices might not be returnable. I believe the only conclusions reached were don't tie to IP revisions in this doc and yuck. Philip Guenther Sendmail, Inc. ** That is, where the envelope sender address's domain either has MX records that point to hosts that only have records, or which has no MX or A records but does have one or more records. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dhc-relay-agent-flags (DHCPv4 Relay Agent Flags Suboption) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv4 Relay Agent Flags Suboption ' draft-ietf-dhc-relay-agent-flags-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-06-04. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-flags-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14818rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: S/MIME Mail Security (smime)
The charter of the S/MIME Mail Security (smime) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ S/MIME Mail Security (smime) == Currect Status: Active Working Group Chair(s): Sean Turner [EMAIL PROTECTED] Blake Ramsdell [EMAIL PROTECTED] Security Area Director(s): Tim Polk [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Tim Polk [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] Archive: http://www.imc.org/ietf-smime/ Description of Working Group: The S/MIME WG was established in the winter of 1997 to define MIME encapsulation techniques of objects whose format was based on PKCS#7 (RFC2315). These encapsulation techniques can be used to provide security services for an arbitrary encapsulated content. Initially the Cryptographic Message Syntax (CMS) (RFC2630) was not algorithm independent; however, the 1st revision separated the syntax (RFC3369) and the algorithms (RFC3370) to allow the two to be updated without affecting one another. Since this split, other documents have been written to document the use of CMS with other algorithms (e.g., ECDSA, AES, GOST). Also since the initial CMS, additional key management techniques (e.g., password-based and an extensible type) and encapsulation techniques (e.g., compression) have been added and other documents have been written to add additional security services. CMS is also transport independent, and documents have been written to define a consistent way to transport MIME objects. The S/MIME specifications, one for the message specification and another for certificate handling, have been updated to migrate algorithms over time. Appropriate WG topics are as follows: - Specifications for the use of additional cryptographic algorithms with CMS. - Specifications that define additional CMS content types. - Specifications to document algorithm migration of S/MIME. - With the approval of the area director, specifications that define additional CMS security services. The WG will perform interoperability testing to progress the CMS and S/MIME Specifications to Draft Standard. Submit S/MIME Message Specification as Proposed Standard Dec 2007 Submit S/MIME Certificate Handling as Proposed Standard Dec 2007 Submit SHA-2 algorithms with CMS as Proposed Standard Dec 2007 Submit CMS as Draft Standard Dec 2008 Submit necessary algorithms documents* as Draft Standard Dec 2008 Submit Enhanced Security Services as Draft Standard Dec 2008 Submit S/MIME Message Specification as Draft Standard Dec 2008 Submit S/MIME Certificate Handling as Draft Standard Dec 2008 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IETF Meeting Schedule 2011 - 2013 #2
All; Based upon feedback received an adjustment was made in March of 2013. Please advise if any further modification to the proposed IETF Meeting schedule below is desired. Thanks Ray Pelletier IAD 2011 16IETF 80Mar 27 - Apr 1 17IETF 81Jul 24 - 29 18IETF 82Nov 13 - 18 2012 21IETF 83Mar 25 - 30 22IETF 84Jul 29 - Aug 3 23IETF 85Nov 4 - 9 2013 26IETF 86Mar 17 - 22 27IETF 87Jul 28 - Aug 2 28IETF 88Nov 3 - 8 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'ESS Update: Adding CertID Algorithm Agility' to Proposed Standard
The IESG has approved the following document: - 'ESS Update: Adding CertID Algorithm Agility ' draft-ietf-smime-escertid-06.txt as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-06.txt Technical Summary This document updates RFC 2634, which defines the SigningCertificate attribute among many other things. The SigningCertificate attribute makes use of ESSCertID, a structure for cryptographically binding the signer's certificate. The ESSCertID structure was hardwired to use the SHA-1 one-way hash function. This document specifies a replacement algorithm agile structure, and it defines a new attribute that uses it. Working Group Summary This document has been reviewed by the S/MIME Working Group, and there is solid support for the document. Many enterprises are looking to ensure S/MIME is not tied to SHA-1. Protocol Quality This document updates RFC 2634. Clear guidance is given as to what sections are replaced, while the remaining text is unaltered. Version numbers are used to allow for easier implementation. This document was reviewed by Tim Polk for the IESG. Note to RFC Editor In section 6., please make the following change: OLD: certHash is computed over the entire DER encoded certificate (including the signature). NEW: certHash is computed over the entire DER encoded certificate (including the signature) using the SHA-1 algorithm. In section 7., please append the following text as new closing paragraphs: The attributes defined in this document permit a signer to select a hash algorithm to identify a certificate. A poorly selected hash algorithm may provide inadequate protection against certificate substitution or result in denial of service for this protection. By employing the attributes defined in this specification with the same hash algorithm used for message signing, the sender can ensure that these attributes provide commensurate security. Since recipients must support the hash algorithm to verify the signature, selecting the same hash algorithm also increases the likelihood that the hash algorithm is supported in the context of certificate identification. Note that an unsupported hash algorithm for certificate identification does not preclude validating the message but does deny the message recipient protection against certificate substitution. To ensure that legacy implementations are provided protection against certificate substitution, clients are permitted to include both ESScertID and ESScertIDv2 in the same message. Since these attributes are generated and evaluated independently, the contents could conceivably be in conflict. Specifically, where a signer has multiple certificates containing the same public key, the two attributes could specify different signing certificates. The result of signature processing may vary depending on which certificate is used to validate the signature. Recipients that attempt to evaluate both attributes may choose to reject such a message. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
