IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-02-04. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Michelle
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
3.3.3 For Action
Telechat:
1259 EST break
1304 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
Telechat:
4.2.2 Proposed for Approval
Telechat:
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1429 EST Adjourned
(at 2010-02-04 08:32:47 PST)
draft-ietf-ccamp-pc-spc-rsvpte-ext
Why is there no "Yes" position? The first sentence of the abstract is long and very hard to read.
I also support Adrien and Russ's DISCUSS
Section 5., paragraph 1:
> An alternative way of getting the LSP related information required
> for the MP to CP handover is also defined in this draft. The
> rationale behind this way is that only a minimal set of information
> is handed over from MP to CP at LSPs Ingress node. Instead of
> collecting within MP all the LSP relevant information down to the
> Label level, formatting it to an ERO and passing it to CP, as in
> previously described solution, it is possible to start with a minimum
> amount of information. The full ERO method and the partial/no ERO
> one do not exclude each other; both methods are required.
DISCUSS: I have one question that I'd like to discuss on the call or
before via email. I fully expect to clear immediately afterwards. If I
understand this correctly, Section 5 describes an alternative
procedure for what is described in Sections 4.1 and/or Section 4.2,
and that both alternatives are REQUIRED to implement. What is the
benefit of this added complexity? I'm not an RSVP-TE expert and maybe
this is obvious if one is, but it doesn't seem worth the complexity to
allow two variants of the same operation that don't seem to have a
very different set of tradeoffs.
Document has idnits issues that should have been fixed before this reached the IESG.
Dan Li wrote an email to Ben Campbell that seems to address his major concern from his GenArt review. (The email is copied below). This needs to be worked up into explanatory text. Ben's other minor points also need to be considered. > Thank you for reviewing our draft and for your valuable comments. > I think that your question arises from the two components of the > process that are required in order to move an LSP between the > management plane and the control plane. > > The first component of the process depends on the normal GMPLS > signaling messages and the use of the H-bit that this draft > defines to be carried in the ADMIN-STATUS object. That component > of the process is invariant. It must always be used to conform to > this document. > > The second component of the process is the information that needs > to be available at each node along the LSP to ensure that the > transition is carried out correctly. There are two possible > situations (assuming we are moving from management plane to > control plane): > > 1. The management plane knows the full path of the LSP (i.e. all > of the nodes, links, component links, and labels/resources for the > whole end-to-end path). This may be the case in some management > systems that have carefully tracked and correlated the LSP as it > was manually provisioned, and in this case the full information > can be provided to the head-end LSR to be encoded in an Explicit > Route Object and signaled using the messages and procedures in the > first component process mentioned above. > > 2. The management plane does not have access to all of the path > information, or is unable to provide it to the head-end LSR for > some reason. This situation might happen for many reasons, but > consider for example a centralized management system that can see > and collect the information, but an operator that wishes to > manually request that the transition is made by entering a > command at the head-end LSR - it would not be sensible to ask > them to type in all of the path information (very error prone). > > The two situations of the second component use exactly the same > messages and objects (described for the first component), and > only differ in how much information is placed in the ERO on the > Path message. In the first case, the full information is present > and directs the behavior at each node - the state in the data > plane is cross-checked against the information in the message. > In the second case, less or no information is placed in the ERO > and each node must inspect the data plane state to work out > exactly what it must do and what information it must pass to the > next hop. > > Please note that there are many similarities here with the way > that LSPs can be set up using the control plane. It is possible > to supply a full and detailed ERO that explicitly controls > exactly what is done at every hop of the path. But it is also > possible to use a "loose ERO" or no ERO at all so that the > routing and label/resource allocation decisions are made hop-by- > hop. These choices have existed in RSVP-TE from day one (RFC 3209) > and exist to give the operator the choice about how to run their > network, and how much management control to exert. > > I hope this explains that the two alternative approaches are not > really different "competing" solutions, but are just different > aspects of the same solution.
The Gen-ART Review by Ben Campbell on 1 Feb 2010 raised one major
concern. Ben asks:
This draft defines two different procedures for accomplishing the
same goal. While it describes them as primary and alternative, it
is not clear to me if an implementation is expected to implement
both of them, or whether they are intended to interoperate. It
would also be helpful to have some guidance on when one might
choose one over the other.
While addressing Ben's major concern, please consider the minor
concerns that he raised as well.
(1) Section 4.2.1.2 and 4.2.2.2 specify "the handover procedure is aborted as
described in
Section 4.1", but I could not resolve the reference. Perhaps the
reference should be to 4.2.1.1?
(2) Section 5 specifies an alternative procedure for MP to CP handover. The
method in section 4
is referred to as the "primary" method, but section 5
indicates "both methods are required."
Does this mean both are mandatory to
implement? If so, what makes the other method
"primary"?
Figure numbers would help the reader considerably.
I support the 'major' concern expressed in the DISCUSSes from Adrian and Russ.
draft-ietf-sipcore-199
INTRODUCTION, paragraph 2: > Response Code for Indication of Terminated Dialog Add something to the title that makes it clear this is for SIP? Section 3., paragraph 1: > REQ 1: It must be possible to indicate to the UAC that an early > dialog has been terminated before a final response is sent. I don't understand the purpose of including this single requirement in this specification document. At least not without further explanation.
The document does not say what track it is targeting. I assume from the ballot that it is intended as Standards Track. Please can you confirm and update the document header. The abbreviations UAC and UAS will need to be expanded in the Abstract and on first usage in the body text.
The Gen-ART Review by Avshalom Houri on 26 Jan 2010 suggested adding references to other relevant RFCs in the Security Considerations. A few editorial changes were suggested. Please consider these changes.
Discuss:
This draft has been discussed in many many WG meetings. Most people gave up and
stopped commenting on it. I do not believe that further working group discussion
will result in any substantial improvements. That said, the draft is not very
useful and has many problems. I would not object to it moving forward as
Experimental. I have substantial issues with it as a PS draft.
The draft lists several reasons that it is useful. I disagree with every single
one of them. (note none of these objections are new, they have all been pointed
out in the WG)
1. Codec release - when resources for a specific codec has been
reserved only for the stream that is terminated. In that case the
resources associated with that codec can be released.
No, lets say that I have loaded iLBC into the DSP and put it in the offer, just
because one dialog that was using iLBC terminates does not mean I can unload it.
It's still int eh SIP offer and I have to accept RTP with that codec.
2. Pre-conditions - when the dialog is terminated, procedures and
resources associated to the pre-conditions for that dialog can be
released.
What resources exactly and how will this help, It's not like I can release one
set of bandwidth before the next allocation comes. This only causes the return
to happen a matter of seconds sooner. I'm unconvinced this offers any compelling
value.
3. In-band security negotiation - when the dialog is terminated,
procedures and resources associated with the in-band security
negotiation for that dialog can be released.
What resources?
4. ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
terminated, procedures and resources associated with the ICE related
in-band procedures for that dialog can be released.
No, the candidates are still in the offer and need to remain valid. I don't
really know what resources this means
5. Limited access resources - in case of forking and multiple stream
it may not be possible to allow early media on all dialogs, so media
sessions associated with some dialogs may e.g. be set to "inactive".
When a dialog is terminated, media sessions associated with other
dialogs can be allowed.
Remind me of a practical scenario where multiple entities on the dialog will be
sending simultaneously early mead. I agree it can happen but it is not at all
clear to me why any of them would terminate the dialing.
6. Secure media selection - when SRTP is used to encrypt the media.
I have no idea what this means. You talking about a few bytes of a MKI mapping
to crypto context ?
"Latching" in SBC is not at all what you describe here. It is the process by
which an SBC decide to send RTP to a IP address that is different than what is
in the SDP.
In the case of early ring tone termination where say a PSTN gateway roles over
to voicemail, I don't see who this will accelerate the move in any useful way
from the PSTN ringback tone to the voicemail server media.
I see no reason to allow this in a Require or proxy-Require and think that
should be a MUST NOT.
It's unclear to me what Reason code to insert or why this is a MUST. The reason
code seems useless for the alleged uses of this mechanism.
The 199 SHOULD/NOT have SDP, please help me understand when it is OK to do that.
Actually probably need to understand when it is OK to violate just about every
SHOULD in the document.
The handling of an INVITE without an offer looks somewhat broken. I Sending an
offer with empty m-lines is not going to cause the call to fail with plenty of
3261 compliant equipment. You need to fix this. I have no idea how to fix it.
You say when a proxy receives an out of dialog 199, it processes it normal. How
exactly is that? If the answer is it forwards it in a stateless way I think this
is a big security problem as I can use that get random people to redirect their
RTP streams to perform DOS attacks.
I could be confused but it looks like section 8 contradicts section 5 on what a
UAS does to send responses containing an offer.
The not sending things reliably that have a Require: 100rel seems like it will
break cretin IDS, firewalls, and middles boxes.
The security considerations section ill be pretty useless for any implementor.
I support the point Sam Weiler made of
I'm also a little worried about the implications of one party or
another trying to continue the dialog, perhaps maliciously, after
sending or receiving one of these. What if one of these were used to
disable a monitoring or billing system, but the parties continued to
use the open session? (Compare to sending a weak C-tone on a
wiretapped PSTN line.)
Section 1 states The 199 response code is an optimization, which allows the UAC to be informed about terminated early dialogs. However, since the support of the 199 response is optional, a UAC cannot assume that it will always receive a 199 provisional response for all terminated early dialogs. Section 4 seems to imply that there are some applications that will not work unless 199 is supported: The UAC SHOULD NOT insert the 199 option- tag in the Require header, unless the particular session usage requires the UAS to support the response code. Also, the UAC SHOULD NOT insert the 199 option-tag in the Proxy-Require header, unless the particular session usage requires every proxy on the path to support the response code. Are these two sections in conflict?
draft-ietf-6man-text-addr-representation
DISCUSS
I would be happy to change my DISCUSS to a YES if the following changes are
made:
DOCUMENT STATUS
As far as I can see, this memo doesn't change anything that goes on the wire. It
is more about textual representations in logs, etc. So, shouldn't it be a BCP as
opposed to a PS document?
OLD TEXT
Leading zeros should be chopped for human legibility and easier
searching. Also, a single 16 bit 0000 field should be represented as
just 0.
NEW TEXT
Leading zeros MUST be supressed. A single 16 bit 0000 field MUST be
represented as 0.
OLD TEXT
The use of "::" should be used to its maximum capability (i.e. 2001:
db8::0:1 is not considered as clean representation).
NEW TEXT
The symbol "::" MUST be used to its maximum capability. For example,
the representation 2001:db8::0:1 is not acceptable, because the symbol "::"
could have been used to produce the shorter representation 2001:db8::1.
OLD TEXT
"::" should not be used to shorten just one 16 bit 0 field for it
would tend to mislead that there are more than one 16 bit field that
is shortened.
NEW TEXT
The symbol "::" MUST not be used to shorten a single 16 bit 0 field.
For example, the representation 2001:db8:1:1:1:1:0:1 is correct. The
representation 2001:db8:1:1:1:1:::1is not.
OLD TEXT
When there is an alternative choice in the placement of a "::", the
longest run of consecutive 16 bit 0 fields should be shortened (i.e.
latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the
consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
the former is shortened. This is consistent with many current
implementations. One idea to avoid any confusion, is for the
operator to not use 16 bit field 0 in the first 64 bits. By nature
IPv6 addresses are usually assigned or allocated to end-users from a
prefix of 32 bits or longer (typically 48 bits or longer).
NEW TEXT
When there is an alternative choice in the placement of a "::", the
longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
latter is
shortened in 2001:0:0:1:0:0:0:1). When the length of the
consecutive 16 bit 0
fields are equal (i.e. 2001:db8:0:0:1:0:0:1), the former MUST BE shortened.
OLD TEXT
Recent implementations tend to represent IPv6 address as lower case.
It
is better to use lower case to avoid problems such as described in section 3.3.3
and 3.4.3.
NEW TEXT
When an IPv6 representation includes the characters "a", "b", "c", "d",
"e" or "f", the MUST be represented in lower case.
Also, the bullet list in Section 8 should include RFC 2119 language.
This document is likely not very useful as a Proposed Standard in its current
form. It needs to be either prescriptive, providing explicit rules through
which arbitrary addresses can be reliably translated into a canonical
representation, or advisory (and published as Informational), as it is
currently, which, e.g., application developers can use as a guideline.
The problem that this document tries to address is in short: "RFC4291 allows
one IPv6 address to be represented by several text strings. This makes it hard
to know which text string to use when dealing with O&M stuff, which is confusing
and error-prone." No disagreement so far.
Based on this, the document says it will specify a "canonical representation" of
IPv6 addresses in text strings what will address these issues (while still being
conformant to, i.e., a subset of, what was allowed by RFC4291.) Consequently, I
was expecting some rules that map an IPv6 address into a single, unique textual
representation (and back).
But the canonical representation in Section 4 doesn't do that. It eliminates
some of the flexibility that RFC4291 allows, but still leaves more than enough
of it (note the absence of MUST) so that none of the confusion Section 3
describes will really be eliminated.
Maybe I misunderstood, but if I didn't, what purpose does this document serve?
Language & grammar are rough. Section 3 is trivial and much too long. Suggest to summarize into 1-2 paragraphs and move the long version to an appendix.
Useful work. Thanks.
Just a couple of points I would like to Discuss before
recommending publication of this document.
It is not clear to me whether this document updates RFC 4291. I would
welcome a quick discussion of this issue.
I am not completely clear on the use of RFC 2119 language in the
document.
Section 4 uses SHOULD and MUST in the preamble, and in my view these words apply
to the whole section and so no further 2119 language is
needed within the
section. However, sections 5 and 6 are outside the
scope of the preamble of
section 4 - should they use 2119 language?
Section 1 I found the Introduction rather terse. I suggest reproducing some of the text from the Abstract. The section would benefit from a reference (presumably to RFC 4291) to show on what you base your address representations OLD All the above point to the same IPv6 address NEW All the above represent the same IPv6 address --- Section 4 The rules in section 4 could be clarified somewhat with examples of good representation and their meaning as full addresses. --- Nit Section 2.2 In case where there are more than one zero fields s/are/is/
I support the DISCUSS position posted by Lars.
I agree a canonical forma is needed for all the reasons provided. But this does
not provide one. Is there any good reasons not to have this RFC define a
canonical form and other RFC and applications can decide if they want to use it
or not.
Section 5: I don't see how an application will know to use hex or decimal for
lower 32 bits. IANA could add new special prefixes at any point in time.
Saying existing system should switch to this is just not really practical. I
would prefer to see has as a specification that future protocols or updates to
protocols could adopt as MUST or SHOULD implement. More specifically, I do not
thing that a PS document like this could imply that some other protocol, say
SIP, was somehow not compliant with the SIP standard if it was not doing it this
way.
I think [2001:db8::1]:80 should be the preferred form for ports.
This feels like a BCP to me, rather than a standards track RFC.
I would prefer to see a single unambiguous representation for display, although I acknowledge that may be difficult to achieve consensus.
Part of the issues were brought-up by OPS-DIR reviewer David Kessens.
1. The intended PS status does not fit the content of the document. The document
fails to define one canonical representation in MUST terms, and the
recommendations in the text are more suitable to an Informational RFC.
2. If the document stays or is modified to stay as standards-track the
requirements in sections 4,5,6 should follow the 2119 capitalization rules.
3. Section 4.2.3 is not clear. It mentions 'former is shortened'. When talking
bits and bytes, it seems better to say something like the 'first sequence of
zero bits'. I have a suspicion what the 'former'
means here but it is not very
well spelled out.
Also:
'One idea to avoid any confusion, is for the operator to not use
16 bit field 0 in the first 64 bits.'
seems a bit strange suggestion to the problem, as there is also a certain
operational convenience in using the easy addresses in the operators network for
example. I suggest leaving this sentence out.
4. in Section 5 - Text Representation of Special Addresses:
Allowing a different canonical notation for addresses with embedded
IPv4
addresses seems to undermine the goal of a canonical notation:
eg. this way
there are really two notations and the advantage of a canonical notation
dispappears. I understant the problem that it is hard to make a choice in that
particular case but I believe that making a choice is better than not making one
and aloowing for exceptions.
1. If the recommendations in the document apply to prefixes and not only to addresses as section 7 seems to indicate this needs to be said in the introduction, maybe even in the title. 2. in section 4.2.1 - 'is not considered as clean representation' does not sound good as a normative sentence - probably better say 'is not recommended' (or 'is NOT RECOMMENDED'). 3. Security considerations - one can make the argument that following the recommendations in this document leads to an increase in the security of the network, by increasing the efficiency of the abuse handling activities as described in 3.3.3, and by eliminating some of the ambiguities in expressing addresses in various formats, which could potentially be exploited for attacks.
Support Lars' discuss In section 4.2.3, these two sentences are particularly hard to parse: "One idea to avoid any confusion, is for the operator to not use 16 bit field 0 in the first 64 bits. By nature IPv6 addresses are usually assigned or allocated to end-users from a prefix of 32 bits or longer (typically 48 bits or longer)." Please consider making it clear that the first sentence is an observation about existing practices, not a recommendation or requirement. I'm not sure what the second sentence is trying to accomplish.
I am supporting Lars and Ralphs discusses. I think specifying a true canonical form at PS level is a good thing. However, the users of this form need to select it themselves.
draft-roach-sip-http-subscribe
When section 3.3 is removed, you will need to remove references 14 and 15. (Assuming you really want to discard 3.3 and not move it to an appendix to retain the history.)
The Gen-ART Review by Suresh Krishnan on 2 Feb 2010 made some suggestions to simplify the document. Please consider them.
draft-ietf-nsis-y1541-qosm
Editorial nit: IN section 2.1, classes 6 and 7 are described in a different way than the other classes. I think the net effect is that the definitions are compatible; however, in reading the document as it stand I wondered if I was missing something different about classes 6 and 7. E.g., 6/7 do not have an introductory summary sentence, and use symbols <= rather than "upper bound": Class 3: Interactive transaction data. Mean delay upper bound is 400 ms, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include signaling. Class 6: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation. Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation.
I assume that [TRQ-QoS-SIG] is Q.Sup51.
According to Recommendation A.13, Supplements are informative and do
not have the backing of full ITU-T Study Group formal approval. In
particular "They do not imply any agreement on the part of ITU-T"
In view of this, it does not seem appropriate to use [TRQ-QoS-SIG]
as a normative reference.
---
Section 2 summarise the concepts documented in Y.1541. This is a useful
section. However, it is not clear to me whether in this draft the
definitions of Y.1541 or the definitions reproduced as summaries are
normative. It is important that there be only one normative source, and
I expect you mean that to be Y.1541. I suggest that the introductory
text of Section 2 should include a note that "the material in this
section is provided for information and to make this document easier
to read, however the normative definitions are found in [Y.1541] and
in the event of any discrpencies, the definitions in that document
take priority."
---
Section 3.1
The QSPEC parameter behavior for the TMOD extended parameter is
similar to that defined in Section 3.3.1 of[I-D.ietf-nsis-qspec].
If it is "similar" then it is different. If so, you need to describe
the differences. If this is documented somewhere else in the I-D then
please give a pointer.
There are some acronyms that could usefully be expanded on first use. --- Section 3.1 TMOD extension parameter It is unusual to allocate whole 32bit words of reserved space for future use. We normally leave out this sort of padding in the knowledge that we can always extend objects in the future. --- Section 4.1 QNEs may be Stateful in some limited aspects, but obviously it is preferable to deploy stateless QNEs. This seems a bit unhelpful. If it needs to be said, it is not "obvious". So you should explain your assertion with a bried reason. "...in some limited aspects" is not very clear. What does it mean?
The Gen-ART Review Brian Carpenter on 19 Jan 2010 raised significant
concerns. I have not seen any discussion of them. They need to be
addressed.
> 3.1. Traffic Model (TMOD) Extension Parameter
>
> The traffic model (TMOD) extension parameter is represented by one
> floating point number in single-precision IEEE floating point format
> and one 32-bit reserved field.
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |M|E|N|r| 15 |r|r|r|r| 2 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Peak Bucket Size [Bp] (32-bit IEEE floating point number) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 1: TMOD Extension
Suddenly we have a protocol element defined in detail, but no explanation
of what protcol it extends. Is this part of a QSPEC, or what? There should
be some explanation and a reference.
Same concern for Section 3.2 and the Restoration Priority Parameter.
Brian suspects that a full analysis would find other hidden normative
statements, such as in Section 4.6, as below.
> 4.6. Preemption Behaviour
>
> The default QNI behaviour of tearing down a preempted reservation is
> followed in the Y.1541 QOSM.
Who is implementing this?
Excerpted from Brian Weis' secdir review: 2. Section 4.4 refers to "the example given in Section 4.4 of [I- D.ietf-nsis-qspec]". Is that the right section? It discusses extensibility of QSPEC, but there's no example. 3. Reference [Y.1221] has "Y.1541" in its title rather than "Y.1221". 4. Reference [Y.2172] has "Y.1540" in its title rather than "Y.2172".
draft-ietf-dkim-deployment
Section 2.2, 3rd paragraph, is quoted from RFC 5672, but the quotation isn't word-by-word exact.
the last sentence before Figure 2 (section 2.5) seems to be missing a closing thought (and closing punctuation): "... but also contacting the signing organization and seeking" seeking what?
draft-ietf-capwap-802dot11-mib
draft-josefsson-kerberos5-starttls
This is an excellent document, and I wanted to vote Yes on it. However,
there is one small but important issue that I wanted to discuss before
doing so. The document says:
To validate a server certificate, the client MAY use local
configuration (e.g., a list that maps the Kerberos realm to a copy of
the server's certificate) and compare that with the authentication
information provided from the server via TLS. For illustration, the
server certificate could be a X.509 certificate or an OpenPGP key.
In this mode, the client need no processing related to id-
krb5starttls-san.
When the server presents a X.509 server certificate, clients MAY use
"Certification Path Validation" as described in [RFC5280] to validate
the KDC server certificate. In addition, unless the client can
otherwise verify that the server certificate is bound to the KDC of
the target realm, the client MUST verify that the server certificate
contains the id-krb5starttls-san SAN and that the value is identical
to the intended Kerberos realm.
In other words, local validation is a MAY, certification path validation
is a MAY, and the only thing that is a MUST is checking that the server
claims to represent the intended Kerberos realm. Is there something
that prevents the server from lying in the SAN? Wouldn't it be proper
to require that either local validation or certification path validation
is a MUST?
I agree with Alexey - we need to discuss the addition of _tls
What review has the proposed _tls extension received?
I like the document and would vote No Objections once my issue is discussed:
4. STARTTLS aware KDC Discovery
Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name
System (DNS) SRV records [RFC2782] can be used to find the address of
an KDC. We define a new Proto of "tls" to indicate that the
particular KDC is intended to support this STARTTLS extension. The
Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target
have the same meaning as in RFC 4120.
For example:
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
We need to discuss how introduction of "_tls" affects DNS SRV registry
reorganization.
To answer my previous comment: the id-krb5starttls-san OID is already allocated, so nothing needs to be done by IANA.
draft-turner-ecprivatekey
The end of Section 1 says: > > When the public key is included, it is present in the ECPrivateKey > publicKey field not in the PKCS#8 publicKey field. > It would be more clear to say: > > There are two possible locations to carry a public key. When one is > included, the publicKey field in the ECPrivateKey is used. The > publicKey field in PKCS#8 is not used. In section 4, the document says: > > Local storage of an unencrypted ECPrivateKey object is out of scope > of this document. However, one popular format uses the .pem file > extension. > PEM files support encrypted storage too. In section 5, the document says: > > Protection of the private-key information is vital to public-key > cryptography. Disclosure of the private-key material to another > entity can lead to masquerades. The encryption algorithm used in the > encryption process must be as 'strong' as the key it is protecting. > This is incomplete. The consequences of disclosure depends on the purpose of the private key. If a private key is used for signature, then the disclosure allows unauthorizes signing. If a private key is used for key management, then disclosure allows unauthorized parties to acess the managed keying material.
draft-nottingham-http-stale-controls